[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: "Andrew D. Ball" <aball@xxxxxxxxxx>
  • Date: Wed, 22 Feb 2006 14:22:53 -0500
  • Delivery-date: Wed, 22 Feb 2006 19:23:15 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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@xxxxxxxxxx

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


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.