Re: [Xen-devel] [PATCH v4 2/2] docs/designs: Add a design document for migration of xenstore data

[Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

On Thu, Jan 30, 2020 at 08:45:49AM +0000, Durrant, Paul wrote:
> > -----Original Message-----
> > From: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
> > Sent: 29 January 2020 21:23
> > To: Durrant, Paul <pdurrant@xxxxxxxxxxxx>
> > Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Stefano Stabellini
> > <sstabellini@xxxxxxxxxx>; Julien Grall <julien@xxxxxxx>; Wei Liu
> > <wl@xxxxxxx>; Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>; George
> > Dunlap <George.Dunlap@xxxxxxxxxxxxx>; Andrew Cooper
> > <andrew.cooper3@xxxxxxxxxx>; Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> > Subject: Re: [Xen-devel] [PATCH v4 2/2] docs/designs: Add a design
> > document for migration of xenstore data
> > 
> > On Wed, Jan 29, 2020 at 02:47:02PM +0000, Paul Durrant wrote:
> > 
> > <snip>
> > 
> > > +**node data**
> > > +
> > > +
> > > +`<path>|<value>|<perm-as-string>|`
> > > +
> > > +
> > > +`<path>` is considered relative to the domain path
> > `/local/domain/$domid`
> > > +and hence must not begin with `/`.
> > 
> > How backend settings are going to be serialized?
> 
> They're not going to be. The toolstack will construct new backends; 
> co-operation will be required from them in that they must support re-binding 
> (which the latest versions of blkback and netback do). We will need to 
> white-list backends that are known to do this and refuse non-cooperative 
> migration if any other backend is use.
> 
> > For example vif backend
> > has a bunch of feature-* entries, which should not change under the
> > guest feet during non-cooperative migration.
> > 
> 
> The frontend will normally come back in 'connected' state, in which case a 
> change in any feature flags will be irrelevant until the next (if any) 
> re-connection (since the protocols only sample them at that point). If the 
> frontend is not connected then it will sample the feature flags in the usual 
> way. If the frontend/backend are in transition then the locking in the 
> backend should prevent the 'unbind' from completing until some level of 
> stability has been reached.

Yes, but regardless of xenstore entries, those do represent what backend
can and is willing to do. If some feature disappears (in actual backend,
not only its xenstore representation) during non-cooperative migration,
I guess frontent won't be happy about that.

How are they related to feature-* entries in frontent? Are frontend
features separate set, or a confirmation what backend's features will be
used?

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel