Re: [PATCH 0/2 V3] fix rename: xenstore not fully updated

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Wed, Nov 19, 2014 at 11:26:32AM +0000, Ian Jackson wrote:
> Hi Konrad, I have another release ack request:
> 
> Chunyan Liu writes ("[PATCH 0/2 V3] fix rename: xenstore not fully updated"):
> > Currently libxl__domain_rename only update /local/domain/<domid>/name,
> > still some places in xenstore are not updated, including:
> > /vm/<uuid>/name and /local/domain/0/backend/<device>/<domid>/.../domain.
> > This patch series updates /vm/<uuid>/name in xenstore,
> 
> This ("[PATCH 2/2 V3] fix rename: xenstore not fully updated") is a
> bugfix which I think should go into Xen 4.5.
> 
> The risk WITHOUT this patch is that there are out-of-tree tools which
> look here for the domain name and will get confused after it is
> renamed.

When was this introduced? Did it exist with Xend?

> 
> The risk WITH this patch is that the implementation could be wrong
> somehow, in which case the code would need to be updated again.  But
> it's a very small patch and has been fully reviewed.

I checked QEMU and didn't find anything in there.

> 
> 
> > and removes the unusual 'domain' field under backend directory.
> 
> This is a reference to "[PATCH 1/2 V3] remove domain field in xenstore
> backend dir".  The change to libxl is that it no longer writes
>   /local/domain/0/backend/vfb/3/0/domain = "name of frontend domain"
> 
> It seems hardly conceivable that anyone could be using this field.
> Existing users will not work after the domain is renamed, anyway.
> 
> The risk on both sides of the decision lies entirely with out-of-tree
> software which looks here for the domain name for some reason.  We
> don't think any such tools exist.
> 
> Note that the domain name cannot be used directly by a non-dom0
> programs because the mapping between domids and domain names is in a
> part of xenstore which is not accessible to guests.  (It is possible
> that a guest would read this value merely to display it.)
> 
> 
> If such out-of-tree software exists:
> 
> The risk WITHOUT this patch is that it might report, or (worse)
> operate on, the wrong domain entirely.
> 
> The risk WITH this patch is that it (or some subset of its
> functionality) would stop working right away.
> 
> 
> An alternative would be to update all of these entries on rename.
> That's a large and somewhat fiddly patch which we don't think is
> appropriate given that the presence of this key is a mistake.
> 
> 
> Thanks,
> ian.