|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] 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@xxxxxxxxxx
"Festina Lente" $\approx$ "Make haste slowly"
-- Caesar Augustus
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-devel] use case for exposing xenstore attributes via sysfs [long],
Andrew D. Ball <=
|
|
|
|
|