6:43 a.m.
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
12:45 p.m.
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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
1:42 p.m.
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).
2:35 p.m.
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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
3:12 p.m.
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.
3:38 p.m.
New subject: [libvirt-users] exposing <actual> [was: QEMU hook on restore]
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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
3:59 p.m.
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?
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.
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.
So, it appears this *isn't* our oppurtunity to expose <actual> (unless
somebody really wants to :-)
8:15 p.m.
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
9:24 a.m.
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?
4 p.m.
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
8:07 p.m.
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
4702
days inactive
4705
days old
10 comments
3 participants
participants (3)
-
Eric Blake -
Laine Stump -
Székelyi Szabolcs