Re: [Xen-devel] Design session report: Live-Updating Xen

[Juergen Gross <jgross@xxxxxxxx>]

On 18.07.19 11:40, Roger Pau Monné  wrote:
> On Thu, Jul 18, 2019 at 11:00:23AM +0200, Juergen Gross wrote:
> > On 17.07.19 00:27, Andrew Cooper wrote:
> > > On 16/07/2019 05:20, Sarah Newman wrote:
> > > > On 7/15/19 8:48 PM, Juergen Gross wrote:
> > > > > On 15.07.19 21:31, Sarah Newman wrote:
> > > > > > On 7/15/19 11:57 AM, Foerster, Leonard wrote:
> > > > > > ...
> > > > > > > A key cornerstone for Live-update is guest transparent live migration
> > > > > > ...
> > > > > > >       -> for live migration: domid is a problem in this case
> > > > > > >           -> randomize and pray does not work on smaller fleets
> > > > > > >           -> this is not a problem for live-update
> > > > > > >           -> BUT: as a community we shoudl make this restriction go away
> > > > > > Andrew Cooper pointed out to me that manually assigning domain IDs
> > > > > > is supported in much of the code already. If guest transparent live
> > > > > > migration gets merged, we'll look at passing in a domain ID to xl,
> > > > > > which would be good enough for us. I don't know about the other
> > > > > > toolstacks.
> > > > > The main problem is the case where on the target host the domid of the
> > > > > migrated domain is already in use by another domain. So you either need
> > > > > a domid allocator spanning all hosts or the change of domid during
> > > > > migration must be hidden from the guest for guest transparent migration.
> > > > Yes. There are some cluster management systems which use xl rather
> > > > than xapi.
> > > > They could be extended to manage domain IDs if it's too difficult to
> > > > allow
> > > > the domain ID to change during migration.
> > > For a v1 feature, having a restriction of "you must manage domids across
> > > the cluster" is a fine.  Guest-transparent migration is a very important
> > > feature, and one where we are lacking in relation to other hypervisors.
> > >
> > > Longer term, we as the Xen community need to figure out a way to remove
> > > the dependency on domids, at which point the cluster-wide management
> > > restriction can be dropped.  This isn't going to be a trivial task, but
> > > it will be a worthwhile one.
> > Another problem are Xenstore watches. With guest transparent LM they are
> > lost today as there is currently no way to migrate them to the target
> > Xenstore.
> Hm, I guess I'm missing something, but xenstored running either in
> dom0 or in a stubdomain should be completely unaware of the hypervisor
> being updated under it's feet. The hypervisor itself don't have any
> knowledge itself of xenstore state.
Oh, right, I was thinking about guest transparent LM first and then
widened the scope to Live Update.

So this is a problem for guest transparent LM only.


Juergen


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