From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xen.org
Subject: Re: What runtime states to be preserved across save / restore?
Date: Mon, 28 Apr 2014 15:39:58 +0100 [thread overview]
Message-ID: <20140428143958.GC28126@zion.uk.xensource.com> (raw)
In-Reply-To: <1398694577.29700.130.camel@kazak.uk.xensource.com>
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.
next prev parent reply other threads:[~2014-04-28 14:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-28 13:10 What runtime states to be preserved across save / restore? Wei Liu
2014-04-28 13:42 ` Ian Campbell
2014-04-28 13:57 ` Wei Liu
2014-04-28 14:16 ` Ian Campbell
2014-04-28 14:39 ` Wei Liu [this message]
2014-04-29 7:29 ` Daniel Kiper
2014-04-29 9:05 ` Wei Liu
2014-04-29 10:40 ` Daniel Kiper
2014-04-29 10:42 ` Wei Liu
2014-05-06 9:32 ` George Dunlap
2014-05-06 9:44 ` Wei Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140428143958.GC28126@zion.uk.xensource.com \
--to=wei.liu2@citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.