Re: [Xen-devel] Strange (???) xl behavior for save, migrate and migrate-receive

[Daniel Kiper <dkiper@xxxxxxxxxxxx>]

On Mon, Oct 17, 2011 at 09:12:05PM +0200, Olaf Hering wrote:
> On Mon, Oct 17, Daniel Kiper wrote:
>
> > During work on memory hotplug for Xen I have received some notices
> > that it breaks machine migration. I had some time and I done some
> > tests a few days ago. It looks that source of this problem is
> > xl command itself. I discovered that generic save/restore mechanism
> > is used for machine migration. xl save store machine config which
> > was used at machine startup with current machine state. It means
> > that it does not take into account any config changes which were made
> > during machine run. This behavior does not allow migrating domain,
> > on which memory hotplug was used, to restore on destination host
> > because current size of memory allocated for machine is larger than
> > size of memory allocated at startup by memory option. Yes, it is
> > memory option not maxmem option. However, it is not important here
> > because I think that generic behavior of xl save, migrate and 
> > migrate-receive
> > should be changed (fix for memory hotplug case is workaround for the
> > generic problem which will return sooner or later). I think that xl save,
> > migrate and migrate-receive should use current machine state and __CURRENT__
> > config (from xenstore ???) to do their tasks. However, I am aware that
> > this change could have large impact on current users. That is why I decided
> > to ask you about your opinion and suggested solutions in that case
> > (in general not memory hotplug only).
>
> Its easy to implement in xl by throwing some xenstore watches into the
> code.
>
> http://lists.xensource.com/archives/html/xen-devel/2011-10/msg00778.html

Thanks. I saw your e-mail eariler, however, I decided to post my one
separetly because it is a bit different case. As you said implementation
is probably easy. However, I do not want break default behavior of
xl without consent with Xen-devel members.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel