Hi, I wonder if there is some (crazy, useful, your choice) way to do the equivalent of the following commands while a new VM is built. (much like adding usb or pci devices works) xenstore-write /local/domain/<id>/new_node "Null" xenstore-chmod /local/domain/<id>/new_node w 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. Also, it would of course be much saner to do it in the VM config instead via some watch-daemon or even udev rules. 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.
On Wed, 2011-11-23 at 20:11 +0000, Florian Heigl wrote:> Hi, > > I wonder if there is some (crazy, useful, your choice) way to do the > equivalent of the following commands while a new VM is built. > (much like adding usb or pci devices works) > > xenstore-write /local/domain/<id>/new_node "Null" > xenstore-chmod /local/domain/<id>/new_node w > > 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.> Also, it would of course be much saner to do it in the VM config > instead via some watch-daemon or even udev rules.You could just start the VM paused, use "xl domid" to setup your keys and then unpause? 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. 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. Ian.
2011/11/24 Ian Campbell <Ian.Campbell@citrix.com>:> 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.
On Thu, 2011-11-24 at 10:31 +0000, Florian Heigl wrote:> 2011/11/24 Ian Campbell <Ian.Campbell@citrix.com>: > > 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".Right.> > > 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.Those options configure the behaviour of xl itself rather than calling out to some hook script.> 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!That''s what I was suggesting by exposing libxl_domain_create_info.xsdata through xl.> 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 >