diff options
author | emellor@leeni.uk.xensource.com <emellor@leeni.uk.xensource.com> | 2006-04-14 21:22:09 +0100 |
---|---|---|
committer | emellor@leeni.uk.xensource.com <emellor@leeni.uk.xensource.com> | 2006-04-14 21:22:09 +0100 |
commit | abd30192c04df508da0c4c3d7803c95125a59e51 (patch) | |
tree | fd34015068ed3f59da6859060737a8439036c9c9 /tools/examples/xend-config.sxp | |
parent | 73b491c2a0fdba23ebd8329a650b2a11ec33fb1f (diff) | |
download | xen-abd30192c04df508da0c4c3d7803c95125a59e51.tar.gz xen-abd30192c04df508da0c4c3d7803c95125a59e51.tar.bz2 xen-abd30192c04df508da0c4c3d7803c95125a59e51.zip |
This patch enables external devices, such as for example a mounted hard
drive image or a TPM, to be migrated to a remote machine. The patch
hooks into the checkpointing (XendCheckpoint.py) code and performs
migration in 4 different steps:
In a 1st step (step = 0 in the code) migration of all devices of a
domain is 'tested', that means their driver implementations (blkif.py,
netif.py, tpmif.py, usbif.py, pciif.py) are queried whether migration is
possible at all. Currently all device representations respond with a
'yes' (=0), although probably a VM mounting a hard drive partition
should respond with a 'no' (-1) already. This first step is a quick
check to see whether devices can be migrated.
The 2nd step is to do whatever can be done before the domain is
suspended. At this point migration of the device could be initiated, if
at all possible.
The 3rd step is to migrate a device after the domain has been suspended,
meaning that it is not scheduled anymore and the VM is 'settled'. All
devices are called again and a good implementation would initiate the
migration in a background process to achieve as much concurrency as
possible.
The 4th step is to synchronize with the 3rd step. At this point the
implementor has to make sure that anything that was initiated in step 3
has completed. Once all steps 4 have been processed, the VM will resume
on the remove machine.
I have implemented hooks for migration of a virtual TPM in
xen/xend/server/tpmif.py. These hooks call a configurable external
migration tool using the os.popen() call with a fixed command line
parameter set. The implementation refuses to migrate a VM attached to a
virtual TPM if no tool has been provided for migration.
All other devices do not currently overload the 'migrate' method defined
in the DevController.py and therefore will just let migration happen.
I have added hooks for error recovery such that whatever part of
migration has been initiated can be rolled back when any of the devices
fail to migrate in one of the steps. The interface (in tpmif.py) to the
external application now uses os.popen() to allow error handling by
reading the application's output.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
Diffstat (limited to 'tools/examples/xend-config.sxp')
-rw-r--r-- | tools/examples/xend-config.sxp | 3 |
1 files changed, 3 insertions, 0 deletions
diff --git a/tools/examples/xend-config.sxp b/tools/examples/xend-config.sxp index 7dd74f793a..00ae08ca0d 100644 --- a/tools/examples/xend-config.sxp +++ b/tools/examples/xend-config.sxp @@ -127,3 +127,6 @@ # Whether to enable core-dumps when domains crash. #(enable-dump no) + +# The tool used for initiating virtual TPM migration +#(external-migration-tool '') |