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. -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@lists.xen.org http://lists.xen.org/xen-devel
