Re: [Xen-devel] Can domU config add userdefined keys to Xenstore?

[Florian Heigl <florian.heigl@xxxxxxxxx>]

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