Xen devel - May 2006 - Q: How to find own domid or uuid from domU?

I can access xenstore /local/domain/DOMID in domU''s kernel through the
xen/xenbus.h API.  What I can''t figure out for love or money is how to
determine DOMID.  Or UUID, for that matter.  Ideas?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 18 May 2006, at 09:32, Markus Armbruster wrote:
> I can access xenstore /local/domain/DOMID in domU''s kernel through
the
> xen/xenbus.h API.  What I can''t figure out for love or money is
how to
> determine DOMID.  Or UUID, for that matter.  Ideas?
DOMID is ephemeral so we don''t want guests looking at it. UUID is a 
different matter -- I think we simply don''t have an interface for 
obtaining it right now.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser <Keir.Fraser@cl.cam.ac.uk> writes:
> On 18 May 2006, at 09:32, Markus Armbruster wrote:
>
>> I can access xenstore /local/domain/DOMID in domU''s kernel
through the
>> xen/xenbus.h API.  What I can''t figure out for love or money
is how to
>> determine DOMID.  Or UUID, for that matter.  Ideas?
>
> DOMID is ephemeral so we don''t want guests looking at it. UUID is
a
> different matter -- I think we simply don''t have an interface for
> obtaining it right now.
>
>  -- Keir
I can map from domid to uuid by reading /local/domain/DOMID/vm.

I got that to work by trying DOMIDs starting with 0 until the read
succeeds, but that''s kind of gross.

I can think of some less gross methods to find my domid, but I''d still
be glad to hear suggestions.

Would you like to have an interface for obtaining one''s UUID?  What
about adding a XENVER_get_uuid code to HYPERVISOR_xen_version()?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 18 May 2006, at 10:46, Markus Armbruster wrote:
> I can map from domid to uuid by reading /local/domain/DOMID/vm.
>
> I got that to work by trying DOMIDs starting with 0 until the read
> succeeds, but that''s kind of gross.
>
> I can think of some less gross methods to find my domid, but I''d
still
> be glad to hear suggestions.
Don''t use DOMID. It can change across save/restore and migration.
> Would you like to have an interface for obtaining one''s UUID? 
What
> about adding a XENVER_get_uuid code to HYPERVISOR_xen_version()?
That might be okay, although even that might appear to change if we 
implement things like VM fork in future.

Why does your guest need to know its ID?

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser <Keir.Fraser@cl.cam.ac.uk> writes:
> On 18 May 2006, at 10:46, Markus Armbruster wrote:
>
>> I can map from domid to uuid by reading /local/domain/DOMID/vm.
>>
>> I got that to work by trying DOMIDs starting with 0 until the read
>> succeeds, but that''s kind of gross.
>>
>> I can think of some less gross methods to find my domid, but
I''d still
>> be glad to hear suggestions.
>
> Don''t use DOMID. It can change across save/restore and migration.
No plans to expose it to anything.  I got interested in it just as a
means to obtain the UUID.
>> Would you like to have an interface for obtaining one''s UUID? 
What
>> about adding a XENVER_get_uuid code to HYPERVISOR_xen_version()?
>
> That might be okay, although even that might appear to change if we
> implement things like VM fork in future.
No problem as long as the information remains available somewhere.
> Why does your guest need to know its ID?
So that managament tools have a way of associating a running domain
with persistent state such as config files, regardless of where on a
network the domain is running at any time.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> That might be okay, although even that might appear to change if we
> implement things like VM fork in future.
Hmmm. That sounds interesting. If was done with CoW, the fork could be
almost instant. You could freeze a running domain, fork (copy) it (and
snapshot the underlying lvm volume), and run the copy to test a
scenario, then roll it back again and test another.

Is that achievable using any combination of existing features at all?

Sounds like we need a domain UUID and an instance UUID...

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 18 May 2006, at 11:52, Markus Armbruster wrote:
>> Why does your guest need to know its ID?
>
> So that managament tools have a way of associating a running domain
> with persistent state such as config files, regardless of where on a
> network the domain is running at any time.
If it''s only management tools looking to obtain info about other 
running domains, there''s already a dom0_op for querying uuid info.

Is there any reason a domain needs to know its *own* uuid?

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser <Keir.Fraser@cl.cam.ac.uk> writes:
> On 18 May 2006, at 11:52, Markus Armbruster wrote:
>
>>> Why does your guest need to know its ID?
>>
>> So that managament tools have a way of associating a running domain
>> with persistent state such as config files, regardless of where on a
>> network the domain is running at any time.
>
> If it''s only management tools looking to obtain info about other
> running domains, there''s already a dom0_op for querying uuid info.
>
> Is there any reason a domain needs to know its *own* uuid?
It''s management tools looking to obtain info about their own domain.

Consider a network-enabled stat-gathering, managing, or monitoring
tool running on domU.  It wants to uniquely identify itself to the
peer.  IP or MAC can work in some environments, but in others they''re
ephemeral.  UUID would be much better.  It''s the only thing that known
never to change, isn''t it?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 18 May 2006, at 14:18, Markus Armbruster wrote:
>> If it''s only management tools looking to obtain info about
other
>> running domains, there''s already a dom0_op for querying uuid
info.
>>
>> Is there any reason a domain needs to know its *own* uuid?
>
> It''s management tools looking to obtain info about their own
domain.
>
> Consider a network-enabled stat-gathering, managing, or monitoring
> tool running on domU.  It wants to uniquely identify itself to the
> peer.  IP or MAC can work in some environments, but in others
they''re
> ephemeral.  UUID would be much better.  It''s the only thing that
known
> never to change, isn''t it?
Ok makes sense.

Adding a new op to the version hypercall will be fine.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Markus Armbruster wrote:
> I can access xenstore /local/domain/DOMID in domU''s kernel through
the
> xen/xenbus.h API.  What I can''t figure out for love or money is
how to
> determine DOMID.  Or UUID, for that matter.  Ideas?
Use relative paths:

  code10:~ # xenstore-read vm
  /vm/0fa9cb1b-1275-7027-9cab-80089db40ed4
  code10:~ # xenstore-read domid
  1

That''s it.  But adding a watch for these doesn''t work (at
least it
didn''t last time I tried), so you can''t easily get notified in
case the
domid changes due to migration or save/restore.

cheers,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
Erst mal heiraten, ein, zwei Kinder, und wenn alles läuft
geh'' ich nach drei Jahren mit der Familie an die Börse.
http://www.suse.de/~kraxel/julika-dora.jpeg

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

I think it would be really, really good if the UUID would be exposed via 
sysfs in domU''s.

Peace.
Andrew

Keir Fraser wrote:

 >
 > On 18 May 2006, at 14:18, Markus Armbruster wrote:
 >
 >>> If it''s only management tools looking to obtain info
about other
 >>> running domains, there''s already a dom0_op for querying
uuid info.
 >>>
 >>> Is there any reason a domain needs to know its *own* uuid?
 >>
 >>
 >>
 >> It''s management tools looking to obtain info about their own
domain.
 >>
 >> Consider a network-enabled stat-gathering, managing, or monitoring
 >> tool running on domU.  It wants to uniquely identify itself to the
 >> peer.  IP or MAC can work in some environments, but in others
they''re
 >> ephemeral.  UUID would be much better.  It''s the only thing
that known
 >> never to change, isn''t it?
 >
 >
 >
 > Ok makes sense.
 >
 > Adding a new op to the version hypercall will be fine.
 >
 >  -- Keir
 >
 >
 > _______________________________________________
 > Xen-devel mailing list
 > Xen-devel@lists.xensource.com
 > http://lists.xensource.com/xen-devel





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Good!  I''ve been strapped for time, but will eventually get around to
it
perhaps.  Mike Day''s been doing excellent work on it.

I think it would be nice if the attribute were called uuid and not vm 
with "/vm/" prepended.  I suppose it''s fine to keep
"vm" as a shortcut,
but a separate UUID attribute is more important, IMHO.

Peace.
Andrew

Keir Fraser wrote:
> 
> On 18 May 2006, at 15:28, Andrew D. Ball wrote:
> 
>> I think it would be really, really good if the UUID would be exposed 
>> via sysfs in domU''s.
>>
>> Peace.
>> Andrew
> 
> 
> We have a sysfs framework for Xen (xen_sysfs.c) submitted from IBM and 
> in our tree. Having a uuid attribute in there sounds fine to me -- feel 
> free to make a patch! You can get the uuid from xenstore as Gerd 
> described, or add a version hypercall to grab it.
> 
>  -- Keir
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 5/18/06, Andrew D. Ball <aball@us.ibm.com>
wrote:
> Good!  I''ve been strapped for time, but will eventually get around
to it
> perhaps.  Mike Day''s been doing excellent work on it.
>
> I think it would be nice if the attribute were called uuid and not vm
> with "/vm/" prepended.  I suppose it''s fine to keep
"vm" as a shortcut,
> but a separate UUID attribute is more important, IMHO.
There''s a uuid node under the vm path.  I.e. you''d do:
vmpath=$(xenstore-read vm)
uuid=$(xenstore-read $vmpath/uuid)

I think exposing this through sysfs would be wrong, there''s no need to
make the kernel aware of any of this.

    christian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Christian Limpach wrote:
> On 5/18/06, Andrew D. Ball <aball@us.ibm.com> wrote:
> 
>> Good!  I''ve been strapped for time, but will eventually get
around to it
>> perhaps.  Mike Day''s been doing excellent work on it.
>>
>> I think it would be nice if the attribute were called uuid and not vm
>> with "/vm/" prepended.  I suppose it''s fine to keep
"vm" as a shortcut,
>> but a separate UUID attribute is more important, IMHO.
> 
> 
> There''s a uuid node under the vm path.  I.e. you''d do:
> vmpath=$(xenstore-read vm)
> uuid=$(xenstore-read $vmpath/uuid)
> 
> I think exposing this through sysfs would be wrong, there''s no
need to
> make the kernel aware of any of this.
It''s not the kernel''s knowing about it that I''m
interested in, but
userspace systems management applications.

It''s essential that management applications running outside of
domU''s
and the dom0''s hosting those domU''s to have a stable method of
correlating output from agents running in the domU''s with their
dom0''s.
  The UUID''s are good for this, but need to be read from xenstore now.

Since I''m interested in <uuid> instead of /vm/<uuid>,
I''d like to see
<uuid> by itself in xenstore.

Make sense?
> 
>    christian
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 5/22/06, Andrew D. Ball <aball@us.ibm.com>
wrote:
> Christian Limpach wrote:
> > There''s a uuid node under the vm path.  I.e. you''d
do:
> > vmpath=$(xenstore-read vm)
> > uuid=$(xenstore-read $vmpath/uuid)
>
> Since I''m interested in <uuid> instead of /vm/<uuid>,
I''d like to see
> <uuid> by itself in xenstore.
Yes, you shouldn''t parse the uuid out of the path you get when reading
the vm node, but instead you should read the uuid node in the domain''s
vm tree, as I described in the text you quoted (*sigh*).

    christian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Christian Limpach wrote:
> On 5/22/06, Andrew D. Ball <aball@us.ibm.com> wrote:
> 
>> Christian Limpach wrote:
>> > There''s a uuid node under the vm path.  I.e.
you''d do:
>> > vmpath=$(xenstore-read vm)
>> > uuid=$(xenstore-read $vmpath/uuid)
>>
>> Since I''m interested in <uuid> instead of
/vm/<uuid>, I''d like to see
>> <uuid> by itself in xenstore.
> 
> 
> Yes, you shouldn''t parse the uuid out of the path you get when
reading
> the vm node, but instead you should read the uuid node in the
domain''s
> vm tree, as I described in the text you quoted (*sigh*).
> 
Sorry -- I should have read more attentively.  Thanks.

Andrew
>    christian
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

"Christian Limpach" <christian.limpach@gmail.com> writes:
> There''s a uuid node under the vm path.  I.e. you''d do:
> vmpath=$(xenstore-read vm)
> uuid=$(xenstore-read $vmpath/uuid)
Works in dom0:

    # xenstore-read vm
    /vm/00000000-0000-0000-0000-000000000000
    # xenstore-read /vm/00000000-0000-0000-0000-000000000000/uuid
    00000000-0000-0000-0000-000000000000

Fails in domU:

    # xenstore-read vm
    /vm/947df77a-58b5-4e3d-9b6c-aa0178d8e133
    # xenstore-read /vm/947df77a-58b5-4e3d-9b6c-aa0178d8e133/uuid
    xenstore-read: couldn''t read path
/vm/947df77a-58b5-4e3d-9b6c-aa0178d8e133/uuid

Please advise.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, May 23, 2006 at 09:52:00AM +0200, Markus Armbruster
wrote:
> "Christian Limpach" <christian.limpach@gmail.com> writes:
> 
> > There''s a uuid node under the vm path.  I.e. you''d
do:
> > vmpath=$(xenstore-read vm)
> > uuid=$(xenstore-read $vmpath/uuid)
> 
> Fails in domU:
> 
>     # xenstore-read vm
>     /vm/947df77a-58b5-4e3d-9b6c-aa0178d8e133
>     # xenstore-read /vm/947df77a-58b5-4e3d-9b6c-aa0178d8e133/uuid
>     xenstore-read: couldn''t read path
/vm/947df77a-58b5-4e3d-9b6c-aa0178d8e133/uuid
Indeed, it''s either broken because we''ve set the permissions
not to
allow domains to have access to the /vm tree or because we don''t allow
domains to read outside of their "home" directory.

    christian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, May 23, 2006 at 09:31:21AM +0100, Christian Limpach wrote:
> On Tue, May 23, 2006 at 09:52:00AM +0200, Markus Armbruster wrote:
> > "Christian Limpach" <christian.limpach@gmail.com>
writes:
> > 
> > > There''s a uuid node under the vm path.  I.e.
you''d do:
> > > vmpath=$(xenstore-read vm)
> > > uuid=$(xenstore-read $vmpath/uuid)
> > 
> > Fails in domU:
> > 
> >     # xenstore-read vm
> >     /vm/947df77a-58b5-4e3d-9b6c-aa0178d8e133
> >     # xenstore-read /vm/947df77a-58b5-4e3d-9b6c-aa0178d8e133/uuid
> >     xenstore-read: couldn''t read path
/vm/947df77a-58b5-4e3d-9b6c-aa0178d8e133/uuid
> 
> Indeed, it''s either broken because we''ve set the
permissions not to
> allow domains to have access to the /vm tree or because we don''t
allow
> domains to read outside of their "home" directory.
Permissions for doing this are set in Xend.  At the moment, for security, we
only allow a domain to look at /local/domain/<domid>, and
/local/domain/0/backend/<device type>/<domid>, IIRC.  If it is
reasonable to
allow a guest to determine its UUID, then we could trivially add that to Xend,
by allowing it to read that particular value from the vm directory.

Ewan.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Ewan Mellor <ewan@xensource.com> writes:
> On Tue, May 23, 2006 at 09:31:21AM +0100, Christian Limpach wrote:
>
>> On Tue, May 23, 2006 at 09:52:00AM +0200, Markus Armbruster wrote:
>> > "Christian Limpach" <christian.limpach@gmail.com>
writes:
>> > 
>> > > There''s a uuid node under the vm path.  I.e.
you''d do:
>> > > vmpath=$(xenstore-read vm)
>> > > uuid=$(xenstore-read $vmpath/uuid)
>> > 
>> > Fails in domU:
>> > 
>> >     # xenstore-read vm
>> >     /vm/947df77a-58b5-4e3d-9b6c-aa0178d8e133
>> >     # xenstore-read /vm/947df77a-58b5-4e3d-9b6c-aa0178d8e133/uuid
>> >     xenstore-read: couldn''t read path
/vm/947df77a-58b5-4e3d-9b6c-aa0178d8e133/uuid
>> 
>> Indeed, it''s either broken because we''ve set the
permissions not to
>> allow domains to have access to the /vm tree or because we
don''t allow
>> domains to read outside of their "home" directory.
>
> Permissions for doing this are set in Xend.  At the moment, for security,
we
> only allow a domain to look at /local/domain/<domid>, and
> /local/domain/0/backend/<device type>/<domid>, IIRC.  If it is
reasonable to
> allow a guest to determine its UUID, then we could trivially add that to
Xend,
> by allowing it to read that particular value from the vm directory.
>
> Ewan.
To me it feels like there''s a rough consensus that there are
legitimate uses for the UUID in domU.

It was pointed out that xenstore isn''t really designed to be used in
anger from domU, and that unprivileged access could create real
problems.

Keir indicated that he''s willing to merge a patch to put the UUID into
sysfs.  Makes sense to me, because the UUID is to be used by
unprivileged processes.

I understand that xen_sysfs may not be accepted upstream, or only with
changes.  Fine with me, I''m not looking for a stable API at this time,
I''m looking for something that works to get us going.  If it goes away
later, tough, welcome to the bleeding edge, go look for something else
that works.

I also understand that this is no precedent for stuffing all kinds of
xenstore data into xen_sysfs.

I was looking into Christian''s suggestion to read a proper UUID key
rather than extracting it from the vm value.  Well, it doesn''t work.
I''ll be happy to revise my patch when it does.

In light of the above and all the other contributions to this thread:
what about merging my patch?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 23 May 2006, at 12:02, Markus Armbruster wrote:
> I was looking into Christian''s suggestion to read a proper UUID
key
> rather than extracting it from the vm value.  Well, it doesn''t
work.
> I''ll be happy to revise my patch when it does.
Allowing domU to access its uuid via xenstore seems reasonable and 
shouldn''t be hard to fix (Ewan?).

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, May 23, 2006 at 12:43:57PM +0100, Keir Fraser wrote:
> 
> On 23 May 2006, at 12:02, Markus Armbruster wrote:
> 
> >I was looking into Christian''s suggestion to read a proper
UUID key
> >rather than extracting it from the vm value.  Well, it doesn''t
work.
> >I''ll be happy to revise my patch when it does.
> 
> Allowing domU to access its uuid via xenstore seems reasonable and 
> shouldn''t be hard to fix (Ewan?).
Done -- the changeset is being regression tested now.

Ewan.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel