Re: [Xen-devel] [PATCH 1/1] xc_domain_restore: Allow QEMU to increase memory

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Apr 14, 2015 at 01:43:38PM -0400, Don Slutz wrote:
> On 04/14/15 05:52, Wei Liu wrote:
> > On Tue, Apr 14, 2015 at 05:40:24PM +0800, Hongyang Yang wrote:
> >>
> >> On 04/14/2015 05:29 PM, Wei Liu wrote:
> >>> On Tue, Apr 14, 2015 at 05:22:31PM +0800, Hongyang Yang wrote:
> >>> [...]
> >>>>> If I understand correctly, the steps are this:
> >>>>>
> >>>>> * 'xl create' makes a VM of size $FOO
> >>>>> * qemu bumps the size to $FOO+$N
> >>>>> * 'xl save' writes $FOO+$N of page data, but the xl config file at the
> >>>>> start of the image still says $FOO
> >>>>> * 'xl restore' creates a vm of size $FOO, then instructs
> >>>>> xc_domain_restore() to put $FOO+$N pages into it.
> >>>>>
> >>>>> I would argue first, that qemu should not play in this area to start 
> >>>>> with.
> 
> 
> With the size of the ROMs unknown outside of QEMU, I do not know how to
> correctly compute this in libxl.
> 
> >>>>> However, the real bug here is that the domain configuration written by
> >>>>> xl save is inaccurate.
> 
> I do not 100% agree.  Since xc_domain_setmaxmem() could have been done,
> this should
> be part of the full domain configuration.  However right now there is no
> way to include
> this value in any of the domain configuration structures.
> 
> >>>> There's a case like COLO:
> >>>> 1. Both Primary/Secondary VM are created first with the same config file
> >>>>    which makes a VM of size $FOO
> >>>> 2. qemu bumps the size to $FOO+$N
> 
> This happens very early.  I do see it reflected in PoD
> (xc_domain_get_pod_target()) data.
> 
> >>>> 3. 'save' writes $FOO+$N of page data
> >>>> 4. 'restore' put $FOO+$N pages into $FOO pages which will cause error
> >>>>
> >>>> Even if you fix the configuration, the bug still exists because the 
> >>>> config
> >>>> only been transferred from Primary to Secondary once at the very 
> >>>> beginning
> >>>> when you execute 'xl remus' command.
> 
> I am hopeful that QEMU has already done it's adjusting before you can do
> this
> command.  Not having used it, I do not know for sure.
> 
> >>>>  The problem is how to let the secondary
> >>>> (restore) side knows the size change? Through a migration command(which 
> >>>> is
> >>>> easier in v2 migration) or some other solution?
> >>> As I said in my reply to Don, the extra memory can be saved during
> >>> domain creation. That would solve this problem.
> 
> The memory does get saved, the extra info is missing.
> 
> >> After migration we'll enter COLO mode, which will continously send 
> >> migration
> >> stream to Secondary. Domain creation only happens before doing live 
> >> migration.
> >>
> > Because now the correct value is recorded during domain creation, it will
> > always be sent to the other end, so there is no need for this kind of
> > hack.
> 
> I will be looking into how to add this info (max_memkb
> (xc_domain_getinfo) or
> max_pages ()xc_domain_getinfolist) to the v1 migration in a compatible way
> with a usage in restore.
> 

Let's see if we can record this in xc image format. I haven't looked,
but George mentioned that it might be possible to do so.

There are certainly other options than the one you propose. I think we
need to agree on a fix before proceeding...

Wei.

> 
>    -Don Slutz
> 
> > Wei.
> >
> >>> Wei.
> >>>
> >>>> Form this point of view, I think Don's solution is one way to solve the
> >>>> problem.
> >>>>
> >>>>> ~Andrew
> >>>>> .
> >>>>>
> >>>> --
> >>>> Thanks,
> >>>> Yang.
> >>> .
> >>>
> >> -- 
> >> Thanks,
> >> Yang.

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