Virtual Machines in Grid Environments: Dynamic Virtual Machines - Grid Computing: Infrastructure, Service, and Applications - page 409

execution as P j in a new group. If a process is woken up from a blocking
pt2pt operation, this operation is repeated in the new group. After migra-
tion, the processes should i rst lookup the local communication state for
corresponding messages before they actually receive messages from their
communication channel. We only highlight the idea here. Interested read-
ers may refer to [ 27 ] for the formal description of the protocols and the
details of the system implementation.
Although we have addressed some of the major technical difi culties,
VE and DVM mobility demand more than the integration of process state
transfer and VM reconstruction. For a complete VE mobility service, the
motility service needs to coordinate VM migrations; identifying the pro-
cesses to be migrated; acquiring and remapping resources; identifying
and requesting a reconi guration and an adaptation service. The system
development of VE mobility as a whole is largely untried at this time.
16.3.3.3 Experimental Tests and Results
The concept of a DVM and its associated mechanisms are new. In the fol-
lowing, through some case studies, we present our current implementa-
tion and some experimental results. They further illustrate the design and
implementation consideration and show the potential of a DVM.
16.3.4 A Case Study of VM Modeling and Incarnation
VM modeling and incarnation is the “core” for the development of a DVM.
In this case study, we show the process of VM modeling and incarnation
step by step, including the establishing DVM prototype and templates,
modeling a DVM with user coni guration, compiling, and validating VMD
scripts, generating platform-independent XML script, and instantiating
and initiating a VM. We apply the proposed modeling and incarnation
method to a virtual environment running SPEC CPU2000. The hardware
and system coni guration of the virtual computing environment is sum-
marized as: (1) a VM running Debian Linux on IA32 architecture; (2) a
CD-ROM drive mapping to the CD image of CPU2000; (3) 256M of RAM;
(4) GNU gcc 3.3.5 that provides a C and a f77 compiler; (5) Intel Fortran
compiler for Linux. The ifort compiler is used as f90 compiler. Because
GNU GCC does not support the f90 compiller we use the FORTRAN com-
piler from Intel instead. Figure 16.6 illustrates the basic type structures of a
DVM. The coni guration is dei ned by the coni guration tree (shown in
Figure 16.7 ) constructed during the compiling time. Each node in the con-
i guration tree corresponds to a resource (inner node) or property (leaf
node) of the a DVM. Each node corresponds to a component or parameter
such as a software package, a disk, a mounting point, and so on. The state-
ments that dei ne some low-level components are pruned for brevity in the
i gures. The DVM-type structure categorizes the software and hardware