[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] external device migrate scripts

xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 11/30/2006 08:19:24 PM:

> ----- Original Message ----
> From: Ewan Mellor <ewan@xxxxxxxxxxxxx>
> To: Tavi Santi <tavi_santi@xxxxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Sent: Thursday, November 30, 2006 11:14:49 PM
> Subject: Re: [Xen-devel] external device migrate scripts
> On Thu, Nov 30, 2006 at 12:50:07PM -0800, Tavi Santi wrote:
> > Hi,
> >
> > I am trying to understand how the restore part of the external device
> > migration works. I made some scripts for external device save, similar to
> > the vtpm ones in /etc/xen/scripts. These scripts will run during migration
> > on the source host.
> >
> > However, I need to make them talk with their counterparts on the
> > destination host and I can't figure out which is the appropriate place to
> > call them from so that I am consistent with the other external devices
> > such as vtpm. Is the restore() in /tools/python/xen/xend/XendCheckpoint.py
> > the answer?
> I think you will have to give us some more information -- what are you
> trying to do?
> Ewan.
> I am trying to migrate blkif devices. I order to manage
> synchronization, I need some
> scripts to run on both sides. I am calling the script on the source using the
> tools/examples/external-device-migrate script, similar to the vtpm
> (I have added a migrate
> method to tools/python/xen/xend/server/blkif.py which can be traced
> back to the save() in
> XendCheckpoint.py). The script on the destination should also be
> called when migration
> starts but I don't really know where from. This is probably because
> I am very new to xen and
> I am missing where the other external devices (like the vtpm) are
> doing the same thing.

For the vTPM there's a migration daemon running on both sides, on the source side for sending the vTPM state and on the destination side for receiving the state. Afterwards the vTPM hotplug script takes care of resuming the operation of a particular vTPM instance.

Now in the case of a block device I would first use soemthing like 'scp' to copy a disk image file to the destination machine. Assuming that that file ends up in the right directory you have done the same thing as the vTPM migration daemon had to do in a more complicated way (transferring the state of a vTPM instance using its own protocol). Anyway, afterwards it's up to the hotplug scripts again to hook up the disk image file and 'resume' operation. If you are able to suspend/resume a VM that uses a disk image file, then there's a good chance that this might work. I am not sure what else you would need to trigger on the target machine.


> Thank you.
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.