| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH][RFC] External device migration
On Thu, Apr 06, 2006 at 03:20:02PM -0400, Stefan Berger wrote:
> Hello!
>
> This is a repost of the previously posted patch that enables external
> devices to be migrated using external (relative to XenD) applications.
>
> 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.
>
>
> Below the updated previous text:
>
> 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.
>
> Please let me know what you think about this idea.
>
> Signed-off-by: Stefan Berger <stefanb@xxxxxxxxxx>
Applied, thanks Stefan.
Are there any documentation patches required?
Cheers,
Ewan.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home