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

[Anthony Liguori <aliguori@us.ibm.com>]

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