Hi All,
It may be a foolish en devour, but I'm trying to make a qemu hook script that
provides the semantics of an old, custom xen block script. The script parses
<disk> info, does some setup based on that, and then rewrites part of the config
based on results of the setup. As an example, here is an XML snippet of a <disk>
device on input to the hook script
<disk type='block' device='disk'>
<driver name='qemu' type='raw'/>
<source dev='some-dev-config'/>
<target dev='vdb' bus='virtio'/>
</disk>
and XML returned by the script
<disk type='block' device='disk'>
<driver name='qemu' type='raw'/>
<source dev='/dev/foo'/>
<target dev='vdb' bus='virtio'/>
</disk>
The hook script performs the setup and substitution in the "prepare" phase, but
I noticed the results are never used when subsequently starting the domain.
Indeed qemuProcessStartHook passes a NULL buffer to virHookCall, so the output
XML of the hook is never collected. Does anyone have objections to using the XML
returned from the "prepare" and "release" hook script phases, similar to how it
is used in the "restore" and "migrate" phases?
WRT the "release" phase, for my hack to work I'd need the original value of the
dev attribute ('some-dev-config' in the above example). ISTR some patches on the
list to add a metadata element for <devices>. Perhaps those patches would come
in handy as a place to store the original dev attribute value.
Thanks for your comments!
Regards,
Jim
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
