[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |