[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] What runtime states to be preserved across save / restore?
On Tue, May 06, 2014 at 10:32:09AM +0100, George Dunlap wrote: > On Tue, Apr 29, 2014 at 11:42 AM, Wei Liu <wei.liu2@xxxxxxxxxx> wrote: > > On Tue, Apr 29, 2014 at 12:40:15PM +0200, Daniel Kiper wrote: > >> On Tue, Apr 29, 2014 at 10:05:26AM +0100, Wei Liu wrote: > >> > On Tue, Apr 29, 2014 at 09:29:10AM +0200, Daniel Kiper wrote: > >> > > On Mon, Apr 28, 2014 at 03:16:17PM +0100, Ian Campbell wrote: > >> > > > On Mon, 2014-04-28 at 14:57 +0100, Wei Liu wrote: > >> > > > > >> > > > > > Other things I can think of right now: > >> > > > > > > >> > > > > > * The devid of each device -- for some classes these can be > >> > > > > > automatically assigned, I'm not really sure if that needs > >> > > > > > preserving or not. > >> > > > > > >> > > > > I don't think so. The receiving end should make its own decision. > >> > > > > >> > > > Having eth0 become eth1 over migrate would be surprising though, > >> > > > wouldn't it? > >> > > > > >> > > > > > * Hotplug of devices more generally > >> > > > > > > >> > > > > > >> > > > > Scripts? If so, they, with the things you mentioned below ... > >> > > > > >> > > > Not script, I meant e.g. xl block-attach and stuff like that. > >> > > > >> > > Do not forget about memory hotplug and in general memory != maxmem. > >> > > This stuff is also important in migration case. > >> > > > >> > > >> > I think max memory and target memory are easy -- I can retrieve them > >> > from xenstore. But where can I get information about memory hotplug? > >> > If the relevant bits are missing in libxl then I think we need another > >> > series to address this problem. > >> > >> I think that target and max memory should be sufficient. I mentioned > > > > Cool! > > > >> about that because when I tested migration with xm a few years ago > >> I was not able to migrate machine which had hotplugged memory. IIRC > >> it happened because migration process refered to config file instead > >> of checking relevant values in xenstore. Acording to my knowledge save > >> and restore machinery is (or was) used for migration. Correct me > >> if I am wrong. > >> > > > > You're right about this. ;-) > > Hmm, speaking of which, you may want to check the Xen-enforced limit > as well. Some toolstacks (such as xapi, and I believe xl) will > optionally lower a VM's memory limit in Xen, so that a VM cannot > balloon back up once it's ballooned down. However, other toolstacks > (such as Oracle's, as I understand it) allow the VMs to balloon > themselves up if they want, and so don't set the limit. Whatever the > limit is should probably be copied across by default. > I grep'ed libxl code. If I'm not mistaken, the "Xen-enforced limit" is done by setting max memory target, which is already preserved in current scheme. Wei. > -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |