From: "Andrew D. Ball" <aball@us.ibm.com>
To: xen-devel@lists.xensource.com
Subject: use case for exposing xenstore attributes via sysfs [long]
Date: Wed, 22 Feb 2006 14:22:53 -0500 [thread overview]
Message-ID: <1140636173.26102.53.camel@localhost.localdomain> (raw)
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
next reply other threads:[~2006-02-22 19:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-22 19:22 Andrew D. Ball [this message]
2006-02-23 4:39 ` use case for exposing xenstore attributes via sysfs [long] Anthony Liguori
2006-02-23 10:25 ` Keir Fraser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1140636173.26102.53.camel@localhost.localdomain \
--to=aball@us.ibm.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.