Re: [Xen-devel] What runtime states to be preserved across save / restore?

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

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.

 -George

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