[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 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? > I see your point. It's fairly to preserve anyway -- just read from xenstore and update a field and that's it. But even if we don't preserve it we're in a place no worse then where we are before. I shall say we have no way to preserve it with current infrastructure so I won't count it as a regression. ;-) > > > * 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. > I see. This is a bit tricky though, as the relavent information is broken down to different place or even impossible to resynthesis. But with the nice new infrastructure we can now update the saved configurations as we attach / detach different devices. Just more coding is required. Wei. > > > The selection of the block device backend is also interesting. If the > > > user didn't select then you want to remember that so the other end can > > > make its own choice about what is best, but if the user asked for > > > something explicit it needs preserving. > > > > > > > ... are already in the config file if user ever specifies them, so > > they are already preserved. > > Great. But the config file doesn't contain hotplugged devices I think. > > Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |