use case for exposing xenstore attributes via sysfs [long]

use case for exposing xenstore attributes via sysfs [long]

[Andrew D. Ball]

I've seen some people asking why exposing xenstore attributes via sysfs
could be useful.  Here's why I would really like to see such a patch
make it into Xen:

I've been working on getting domU's to know enough about themselves to
be manageable.  I require a 128-bit UUID for each domU, and I require
that each domU be able to determine its own UUID in userspace.  These
requirements aren't due to my trying to be difficult -- they are to ease
integration of Xen into existing system management tools.  DCE UUID's
for regular hardware are very common and standardized.

Having one agreed-upon 128-bit UUID is very important to me, because I
have been working on extending some of the full virtualization code to
provide SMBIOS tables for fully virtualized domU's.  Reading the SMBIOS
type 1 table is the only way that I know of for programs to find out the
UUID of the system they're running on for regular hardware, so in order
to get fully virtualized domU's to work as I expect them to, I need a
value to use for filling in the UUID in SMBIOS that everyone will be
happy with.

So, if I use the xenstore UUID for both para-virtualized and fully
virtualized domU's, I need to somehow read a para-virtualized domU's
xenstore UUID in userspace on that domU.  

At the moment, I require libxenstore and libxenctrl in the domU.  I read
the 'vm' xenstore attribute in the domU's xenstore home directory, which
is a string representation of the full path in xenstore to the domU's
entry in the "/vm" section of xenstore.  That path includes the domU's
xenstore UUID.

libxenctrl is needed because the best way to read xenstore in userspace
on a domU at the moment involves opening /proc/xen/xenbus and doing
ioctl()'s.  I do not want to do the ioctl()'s manually, without
libxenstore and libxenctrl.

Requiring libxenstore and libxenctrl is a headache, because I'm required
to get my tooling to work on SLES, and so far I see these libraries in
the same package as the rest of the xm tools.  I could require users to
just install the whole xen-tools RPM, but that contains far more than
just these two libraries.  

I could also just pass "uuid=<128-bit-uuid>" as an extra parameter to
the kernel and just read "/proc/cmdline" on the domU's, but I would
prefer not to make domU configurations any more complicated than
necessary.

If I could just use sysfs to read a para-virtualized domU's UUID in that
domU, my work would be considerably simpler, easier, and more elegant.

Please let me know what you think about this approach.

Andrew
=================
-- 
Andrew D. Ball
aball@us.ibm.com

"Festina Lente" $\approx$ "Make haste slowly"
  -- Caesar Augustus

Re: use case for exposing xenstore attributes via sysfs [long]

[Anthony Liguori]

This is an argument for making every application expose an interface 
through sysfs.

I think a more compelling argument to make is that there should be a 
xenbusfs or perhaps a more trivial xenbus interface.  If one could read 
an attribute with something as simple as:

char result[1024];
fd = open("/dev/xen/xenbus", O_RDWR);
xenbus_request.path = "uuid";
xenbus_request.result = result
xenbus_request.result_len = 1024;
ioctl(fd, XENBUS_IOCREAD, &xenbus_request);

It would also solve the general problem too.  There's a really 
interesting article on LWN right now about sysfs being part of the Linux 
userspace ABI.  If we expose parts of XenStore that aren't frozen (all 
of the Xend stuff which includes UUID isn't frozen) via sysfs then it 
would be wrong to ever change those things.

I think you could write up a pretty simple module that provided this for 
domUs.  Would having a simpler kernel interface for XenBus be 
acceptable?   We could just change xenstore-* to use that interface and 
get rid of xenstore_domain_open() (is anyone actually using this 
interface anywhere else?).

Regards,

Anthony Liguori

Andrew D. Ball wrote:
> I've seen some people asking why exposing xenstore attributes via sysfs
> could be useful.  Here's why I would really like to see such a patch
> make it into Xen:
>
> I've been working on getting domU's to know enough about themselves to
> be manageable.  I require a 128-bit UUID for each domU, and I require
> that each domU be able to determine its own UUID in userspace.  These
> requirements aren't due to my trying to be difficult -- they are to ease
> integration of Xen into existing system management tools.  DCE UUID's
> for regular hardware are very common and standardized.
>
> Having one agreed-upon 128-bit UUID is very important to me, because I
> have been working on extending some of the full virtualization code to
> provide SMBIOS tables for fully virtualized domU's.  Reading the SMBIOS
> type 1 table is the only way that I know of for programs to find out the
> UUID of the system they're running on for regular hardware, so in order
> to get fully virtualized domU's to work as I expect them to, I need a
> value to use for filling in the UUID in SMBIOS that everyone will be
> happy with.
>
> So, if I use the xenstore UUID for both para-virtualized and fully
> virtualized domU's, I need to somehow read a para-virtualized domU's
> xenstore UUID in userspace on that domU.  
>
> At the moment, I require libxenstore and libxenctrl in the domU.  I read
> the 'vm' xenstore attribute in the domU's xenstore home directory, which
> is a string representation of the full path in xenstore to the domU's
> entry in the "/vm" section of xenstore.  That path includes the domU's
> xenstore UUID.
>
> libxenctrl is needed because the best way to read xenstore in userspace
> on a domU at the moment involves opening /proc/xen/xenbus and doing
> ioctl()'s.  I do not want to do the ioctl()'s manually, without
> libxenstore and libxenctrl.
>
> Requiring libxenstore and libxenctrl is a headache, because I'm required
> to get my tooling to work on SLES, and so far I see these libraries in
> the same package as the rest of the xm tools.  I could require users to
> just install the whole xen-tools RPM, but that contains far more than
> just these two libraries.  
>
> I could also just pass "uuid=<128-bit-uuid>" as an extra parameter to
> the kernel and just read "/proc/cmdline" on the domU's, but I would
> prefer not to make domU configurations any more complicated than
> necessary.
>
> If I could just use sysfs to read a para-virtualized domU's UUID in that
> domU, my work would be considerably simpler, easier, and more elegant.
>
> Please let me know what you think about this approach.
>
> Andrew
> =================
>   

Re: use case for exposing xenstore attributes via sysfs [long]

[Keir Fraser]

On 23 Feb 2006, at 04:39, Anthony Liguori wrote:

> It would also solve the general problem too.  There's a really 
> interesting article on LWN right now about sysfs being part of the 
> Linux userspace ABI.  If we expose parts of XenStore that aren't 
> frozen (all of the Xend stuff which includes UUID isn't frozen) via 
> sysfs then it would be wrong to ever change those things.
>
> I think you could write up a pretty simple module that provided this 
> for domUs.  Would having a simpler kernel interface for XenBus be 
> acceptable?   We could just change xenstore-* to use that interface 
> and get rid of xenstore_domain_open() (is anyone actually using this 
> interface anywhere else?).

It gets harder if anyone wants to construct transactions or register 
watches from user space. We could support both interfaces though 
(simple restricted, and complex flexible).

  -- Keir