[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Can domU config add userdefined keys to Xenstore?
2011/11/24 Ian Campbell <Ian.Campbell@xxxxxxxxxx>: > On Wed, 2011-11-23 at 20:11 +0000, Florian Heigl wrote: >> I would like to create the entry right at domU launch, and I'd like to >> make use of Xens knowledge of the domU ID it'll use, because the changing >> domU ID is a grief. > > FWIW you can use "xl domid <name>" in your scripts. Ok, nice to know, cleaner than xl list | awk ... > You could just start the VM paused, use "xl domid" to setup your keys > and then unpause? This will all need wrapping around domU creation, so it would mean that it's not possible to use the normal /etc/init.d/xendomains For me, no problem I had to replace that anyway, but in general maybe not so "transparent". > If you are using xapi then VM.xenstore_data is a list of key-value pairs > which is written xenstore. AFAICT The key is relative to > to /local/domain/<id> and must start "vm-data/..." (i.e. you can only > write to keys under /local/domain/<id>/vm-data/ using this mechanism). > > I suspect you aren't using xapi but the reason I mention it is that > someone added libxl_domain_create_info.xsdata in the early days of > libxl, presumably with this purpose in mind, but it appears not to be > hooked up into the xl configuration parser. I expect doing so would be a > reasonably simply job. I'm not using Xapi, yup. But that seems a nice feature. > Another, possibly more flexible but more complex option, would be to > allow for a series of hook scripts (both global and domain specific?) to > be called at various points in a VM lifecylce, including after building > but before starting. There are already kind of hooks in the "on_reboot" "on_destroy" things. but thats quite in hazy future I guess. And it might be overkill. It would be enough if the things you can add into a VM are configured in the same way, in the same place and run at start / stop! Ok. Technically the xenstore /vm/domain/XX is not IN the VM. :) I'll poke around some more, either something using the udev xen backend or the easy and safe route with a small shellscripty-daemon. Many people have looked for some way to find out the xen host's name from within a domU, it's pity this stuff isn't more obvious since it's quite nice to use (just consider stateless linux boxes) Oh and THANKS to whomever wrote the Xenstore articles during last doc day. I was amazed when I found them. Greetings, Florian -- the purpose of libvirt is to provide an abstraction layer hiding all xen features added since 2006 until they were finally understood and copied by the kvm devs. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |