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@us.ibm.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@us.ibm.com>Applied, thanks Stefan. Are there any documentation patches required? Cheers, Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefan Berger
2006-Apr-14 20:38 UTC
Re: [Xen-devel] [PATCH][RFC] External device migration
Ewan Mellor <ewan@xensource.com> wrote on 04/14/2006 04:23:30 PM:> 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. > > > > Applied, thanks Stefan. > > Are there any documentation patches required?I will look into this. Stefan> > Cheers, > > Ewan._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel