[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, 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
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.

Daniel

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.