Xen devel - Feb 2006 - use case for exposing xenstore attributes via sysfs [long]

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


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

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
> ================>   

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

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


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