Re: [Xen-devel] Test report: Migration from 4.1 to 4.2 works

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2012-09-10 at 15:42 +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: Test report: Migration from 4.1 to 4.2 works"):
> >   xc: Saving memory: iter 1 (last sent 134144 skipped 1553): 0/1048576
> >   0%xc: error: Failed to allocate memory for batch.!: Internal error
> 
> 15:22 <ijc> It might be interesting to compare the actual memory usage
>             of the same domain started with xend and xl on 4.1/4.2?
> 
> Started with xl create:
> 
> root@potato-beetle:~# xl list
> Name                                        ID   Mem VCPUs      State   
> Time(s)
> Domain-0                                     0   512     4     r-----     
> 641.0
> win.guest.osstest                           10   507     2     -b----     
> 223.4
> root@potato-beetle:~#
> 
> Then switched to xend:
> 
> root@potato-beetle:~# /etc/init.d/xend start
> root@potato-beetle:~# xenstore-rm /local/domain/0/libxl/disable_udev
> 
> Started with xm create:
> 
> root@potato-beetle:~# xl list
> Name                                        ID   Mem VCPUs      State   
> Time(s)
> Domain-0                                     0   512     4     r-----     
> 720.9
> win.guest.osstest                           11   515     2     ------     
> 238.0
> root@potato-beetle:~#
> 
> I think what is happening is this: xend accounts memory differently to
> xl, giving the guest actually slightly more than is specified in the
> config file.  When xl during incoming migration reads the guest config
> file, it assumes that the config file's memory maximum is an accurate
> representation of the guest's actual memory use.
> 
> I can reproduce this problem by ballooning a PV guest before migrating
> it.  Eg,
>    xl create /etc/xen/debian.guest.osstest.cfg
> with memory=512, maxmem=1024.  Then
>    xl migrate debian.guest.osstest localhost
> works but
>    xl mem-set debian.guest.osstest 1024
>    xl migrate debian.guest.osstest localhost
... "does not". I guess?

This is another facet of the problem with migrating based on the stored
config without taking into account dynamic changes made since the domain
was started.

> I think we need to fix this in 4.2.1 somehow.

The official workaround in 4.2.x is to use "xl config-update" to store a
new config file describing the new state of the domain when you change
its properties at runtime.

In 4.3 I'd like to add functionality to libxl to reconstitute a
libxl_domain_config from a running domain and use that instead of
reparsing the config for migrating/reboot etc. I think it's the only way
to handle these sorts of situations sanely.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel