[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 02:42:13PM +0100, Ian Campbell wrote: > On Mon, 2014-04-28 at 14:10 +0100, Wei Liu wrote: > > Hi all > > > > I'm trying to determine what runtime states to be preserved across > > save / restore. > > > > Things that are randomly generated if not set, definitely want to > > preserve: > > 1. guest uuid > > 2. mac address > > 3. vtpm uuid > > > > Things might change when guest is running, and seem to be worthy of > > preserving: > > 1. max memory size > > 2. target memory size > > 3. CDROM state > > > > As for other things, I think using the stored configurations and let the > > remote end make its own decision is sufficient. > > > > Thoughts? > > I think the above looks pretty sensible. > > 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. > * Hotplug of devices more generally > Scripts? If so, they, with the things you mentioned below ... > 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. > But more generally by making a baseline working version of this stuff > work at all you are also adding the moving parts which we would need to > fix any bugs which we later discover because we've not preserved > something. > Sure. Then I will commence with my current list. Wei. > Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |