[libvirt-users] QEMU hook on restore
Hi, I'm using libvirt 0.8.3. It looks like to me that when a QEMU domain is restored from save, the hook is called with the "stopped end -" arguments. I've also noticed that the domain description passed to the hook script doesn't contain the network device the host will be attached to (XPath: /domain/devices/interface/target/@dev). Are these a bugs or a features? Thanks, -- cc
On 02/10/2012 05:43 AM, Székelyi Szabolcs wrote:
Hi,
I'm using libvirt 0.8.3. It looks like to me that when a QEMU domain is restored from save, the hook is called with the "stopped end -" arguments.
That sounds like a bug, although I haven't yet looked in the code to see for sure. Are you sure you are not getting confused with the hook invocation issued at the time the save completes? At any rate, I agree that both saving and restoring a domain should trigger hooks, and that we ought to make sure the hook arguments are recognizable as distinct from normal stop and start events.
I've also noticed that the domain description passed to the hook script doesn't contain the network device the host will be attached to (XPath: /domain/devices/interface/target/@dev).
This is a different question; right now it is a feature that we don't ever expose the actual network device through dumpxml to the user. But given your use case of a hook, we might have a reason to do it after all. Laine, thoughts? -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 02/10/2012 01:45 PM, Eric Blake wrote:
On 02/10/2012 05:43 AM, Székelyi Szabolcs wrote:
I've also noticed that the domain description passed to the hook script doesn't contain the network device the host will be attached to (XPath: /domain/devices/interface/target/@dev). This is a different question; right now it is a feature that we don't ever expose the actual network device through dumpxml to the user. But given your use case of a hook, we might have a reason to do it after all. Laine, thoughts?
I don't recall why I chose to not expose it in a live dumpxml. I would have to take some time rewinding to remember. It could be I just didn't see a need for polluting public API at the time (and it's always easier to add something in later than to take it away).
On 02/10/2012 12:42 PM, Laine Stump wrote:
On 02/10/2012 01:45 PM, Eric Blake wrote:
On 02/10/2012 05:43 AM, Székelyi Szabolcs wrote:
I've also noticed that the domain description passed to the hook script doesn't contain the network device the host will be attached to (XPath: /domain/devices/interface/target/@dev). This is a different question; right now it is a feature that we don't ever expose the actual network device through dumpxml to the user. But given your use case of a hook, we might have a reason to do it after all. Laine, thoughts?
I don't recall why I chose to not expose it in a live dumpxml. I would have to take some time rewinding to remember. It could be I just didn't see a need for polluting public API at the time (and it's always easier to add something in later than to take it away).
That's my recollection as well - we didn't want to expose it if we didn't see a use; knowing full well that we could turn it on later (but could not turn it off later if it was on from the get-go). Sounds like we're in agreement then on turning it on. Is it best to do that by adding a new flags bit to dumpxml? -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 02/10/2012 03:35 PM, Eric Blake wrote:
On 02/10/2012 12:42 PM, Laine Stump wrote:
On 02/10/2012 01:45 PM, Eric Blake wrote:
On 02/10/2012 05:43 AM, Székelyi Szabolcs wrote:
I've also noticed that the domain description passed to the hook script doesn't contain the network device the host will be attached to (XPath: /domain/devices/interface/target/@dev). This is a different question; right now it is a feature that we don't ever expose the actual network device through dumpxml to the user. But given your use case of a hook, we might have a reason to do it after all. Laine, thoughts?
I don't recall why I chose to not expose it in a live dumpxml. I would have to take some time rewinding to remember. It could be I just didn't see a need for polluting public API at the time (and it's always easier to add something in later than to take it away). That's my recollection as well - we didn't want to expose it if we didn't see a use; knowing full well that we could turn it on later (but could not turn it off later if it was on from the get-go). Sounds like we're in agreement then on turning it on. Is it best to do that by adding a new flags bit to dumpxml?
I think if it's going to be turned on, it can just be included in any output of live xml. One potential problem with this is that, as it stands, someone wanting to know, e.g., which ethernet device a guest interface is connected to with macvtap will need to look in two places - 1) if there is no <actual> element, then it will be in <source dev='ethX'/> under the main interface element, but if there *is* an <actual>, then it's <source dev='ethX'/> under <actual>. (In other words, if the original interface type isn't 'network', then <actual> won't be filled in. The question then is whether or not we *want* it filled in.) An alternate implementation would be to write live XML to the public API as if the interface config acquired from the network definition had been hand-configured. So, for example, if the original config was: <interface type='network'> <mac address='52:54:00:1e:0d:8a'/> <source network='test-direct'/> <model type='virtio'/> </interface> and the current "status" xml (that libvirt stores privately) was: <interface type='network'> <mac address='52:54:00:1e:0d:8a'/> <source network='test-direct'/> <actual type='direct'> <source dev='eth0' mode='bridge'/> </actual> <target dev='macvtap0'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </interface> maybe the live xml output to the public API could be: <interface type='direct'> <mac address='52:54:00:1e:0d:8a'/> <source dev='eth0' mode='bridge'/> <target dev='macvtap0'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </interface> (basically moving everything in <actual> up to <interface>). This would make it easier for people trying to do report status kinds of things, and the loss of original config data wouldn't be a problem here, but I don't know if that would be an acceptable practice.
On 02/10/2012 02:12 PM, Laine Stump wrote:
I think if it's going to be turned on, it can just be included in any output of live xml.
One potential problem with this is that, as it stands, someone wanting to know, e.g., which ethernet device a guest interface is connected to with macvtap will need to look in two places - 1) if there is no <actual> element, then it will be in <source dev='ethX'/> under the main interface element, but if there *is* an <actual>, then it's <source dev='ethX'/> under <actual>. (In other words, if the original interface type isn't 'network', then <actual> won't be filled in. The question then is whether or not we *want* it filled in.)
Good point - making a user search two places isn't very convenient.
An alternate implementation would be to write live XML to the public API as if the interface config acquired from the network definition had been hand-configured.
(basically moving everything in <actual> up to <interface>). This would make it easier for people trying to do report status kinds of things, and the loss of original config data wouldn't be a problem here, but I don't know if that would be an acceptable practice.
I don't like that as the default action. Too many people do 'virsh dumpxml' on a live machine, then use that as the template to configure a new machine, and collapsing the <actual> into the configured portion means that use of the XML as a template would create a different result next time (tying the interface to one port, rather than leaving it associated with a network pool). But under the control of a flag, that sounds nice. Maybe that argues for this approach: dumpxml, flags == 0 => output <actual>, user must search two places dumpxml, flags == DUMP_ACTUAL => rewrite XML to merge actual into the configuration slot, so that user only has to search one place -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 02/10/2012 01:45 PM, Eric Blake wrote:
On 02/10/2012 05:43 AM, Székelyi Szabolcs wrote:
Hi,
I'm using libvirt 0.8.3. It looks like to me that when a QEMU domain is restored from save, the hook is called with the "stopped end -" arguments.
I've also noticed that the domain description passed to the hook script doesn't contain the network device the host will be attached to (XPath: /domain/devices/interface/target/@dev). This is a different question; right now it is a feature that we don't ever expose the actual network device through dumpxml to the user. But given your use case of a hook, we might have a reason to do it after all. Laine, thoughts?
From the documentation page, it looks like the "prepare" hook didn't exist until 0.9.0; my guess would be that the xml sent to the hook for "start" pre-0.9.0 was the static xml (direct from the config), and when
Looking back at the first paragraph, I see that Székely is using libvirt 0.8.3, which didn't have forward mode='bridge' networks anyway, and thus has no such thing as "<actual>", so this isn't his problem. As a matter of fact, what he's looking for is the name of the tap device. I just checked with libvirt-0.9.9, and see that in fact <target dev='xxx'/> isn't given in the *first* time the hook script is called for the domain (when $2 == "prepare"). However, it *is* there the second time the hook script is called (when $2 == "begin"). That's because during the first hook it hasn't yet been determined. the earlier hook was added, this behavior was changed. So, it appears this *isn't* our oppurtunity to expose <actual> (unless somebody really wants to :-)
On 2012. February 10. 16:59:09 Laine Stump wrote:
On 02/10/2012 01:45 PM, Eric Blake wrote: From the documentation page, it looks like the "prepare" hook didn't exist until 0.9.0; my guess would be that the xml sent to the hook for "start" pre-0.9.0 was the static xml (direct from the config), and when the earlier hook was added, this behavior was changed.
There's some incosistency here then: when the domain is actually started (with create or migrate --live), the full XML is provided, but when it's restored from save, then only the static part. (Speaking about 0.8.3.) -- cc
On 02/12/2012 09:15 PM, Székelyi Szabolcs wrote:
On 2012. February 10. 16:59:09 Laine Stump wrote:
On 02/10/2012 01:45 PM, Eric Blake wrote: From the documentation page, it looks like the "prepare" hook didn't exist until 0.9.0; my guess would be that the xml sent to the hook for "start" pre-0.9.0 was the static xml (direct from the config), and when the earlier hook was added, this behavior was changed. There's some incosistency here then: when the domain is actually started (with create or migrate --live), the full XML is provided, but when it's restored from save, then only the static part. (Speaking about 0.8.3.)
That's possible, I don't have anything that runs that old a version of libvirt to check. But it appears that inconsistency doesn't exist in 0.9.10. and 0.8.3 is nearly two years old at this point. Is there any way you can upgrade to something more recent?
On 2012. February 13. 10:24:37 Laine Stump wrote:
That's possible, I don't have anything that runs that old a version of libvirt to check. But it appears that inconsistency doesn't exist in 0.9.10. and 0.8.3 is nearly two years old at this point. Is there any way you can upgrade to something more recent?
Yes, I know... It's Debian stable. :S I'll try 0.9.8 from backports and report the results. Thanks, -- cc
On 2012. February 10. 11:45:49 Eric Blake wrote:
On 02/10/2012 05:43 AM, Székelyi Szabolcs wrote:
I'm using libvirt 0.8.3. It looks like to me that when a QEMU domain is restored from save, the hook is called with the "stopped end -" arguments. That sounds like a bug, although I haven't yet looked in the code to see for sure. Are you sure you are not getting confused with the hook invocation issued at the time the save completes?
Yes. A few days have passed between the save and restore. I'm logging to syslog from the hook scripts, and the timestamps clearly confirm this.
At any rate, I agree that both saving and restoring a domain should trigger hooks, and that we ought to make sure the hook arguments are recognizable as distinct from normal stop and start events.
I've also noticed that the domain description passed to the hook script doesn't contain the network device the host will be attached to (XPath: /domain/devices/interface/target/@dev).
This is a different question; right now it is a feature that we don't ever expose the actual network device through dumpxml to the user.
That's strange, since the same hook is definitely provided this info when the domain is started from scratch (in contrary to when it's restored).
But given your use case of a hook, we might have a reason to do it after all.
This particular hook sets up L2 firewalls to provide virtual network isolation; thus is has to know the host interface to assemble the correct ebtables rules. Thanks, -- cc
participants (3)
-
Eric Blake -
Laine Stump -
Székelyi Szabolcs