Re: [Xen-devel] external device migrate scripts

[Stefan Berger <stefanb@xxxxxxxxxx>]

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.

  Stefan


> 
> 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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel