[libvirt] attach_device incompatibility between libvirt and qemu 0.12

Gerhard Stenzel gstenzel at linux.vnet.ibm.com
Thu Jan 14 12:44:32 UTC 2010


Hi, I have a small libvirt-tck test script, in which I create a domain
without a NIC, then use attach_device to add a NIC. And then I do a ping
test to the domain. This stopped working after updating to latest fedora
and libvirt levels. After some hours, I now discovered that downgrading
to qemu 0.11 fixes it. So there seems to be some incompatibility with
qemu 0.12 and latest libvirt.

The expected output with qemu-system-x86-0.11.0-12.fc12.x86_64:

/usr/share/libvirt-tck/tests/scripts/network/100-ping-still-working.t .. 
1..5
# Trying domain lookup by name
ok 1 - the running domain object
# Attaching the new interface d0:f:d0:f:2:1
ok 2 - interface has been attached
# xml contains mac address element (should be 1)
# 1
ok 3 - running domain has an ID > 0
# waiting for guests to boot
# PING 192.168.1.101 (192.168.1.101) 56(84) bytes of data.
# 64 bytes from 192.168.1.101: icmp_seq=1 ttl=64 time=2.17 ms
# 64 bytes from 192.168.1.101: icmp_seq=2 ttl=64 time=0.554 ms
# 64 bytes from 192.168.1.101: icmp_seq=3 ttl=64 time=0.510 ms
# 64 bytes from 192.168.1.101: icmp_seq=4 ttl=64 time=0.508 ms
# 64 bytes from 192.168.1.101: icmp_seq=5 ttl=64 time=0.505 ms
# 64 bytes from 192.168.1.101: icmp_seq=6 ttl=64 time=0.673 ms
# 64 bytes from 192.168.1.101: icmp_seq=7 ttl=64 time=0.528 ms
# 64 bytes from 192.168.1.101: icmp_seq=8 ttl=64 time=0.522 ms
# 64 bytes from 192.168.1.101: icmp_seq=9 ttl=64 time=0.506 ms
# 64 bytes from 192.168.1.101: icmp_seq=10 ttl=64 time=0.546 ms
# 
# --- 192.168.1.101 ping statistics ---
# 10 packets transmitted, 10 received, 0% pacFor the working I see the
following lines in the log:
ket loss, time 9002ms
# rtt min/avg/max/mdev = 0.505/0.703/2.178/0.493 ms
ok 4 - ping 192.168.1.101 test
# cleaning up
# Detaching the 1st interface d0:f:d0:f:2:1
ok 5 - interface has been detached
ok
All tests successful.
Files=1, Tests=5, 20 wallclock secs ( 0.02 usr  0.01 sys +  0.22 cusr
0.15 csys =  0.40 CPU)
Result: PASS

The failing output with qemu-system-x86-0.11.0-12.fc12.x86_64:

/usr/share/libvirt-tck/tests/scripts/network/100-ping-still-working.t .. 
1..5
# Trying domain lookup by name
ok 1 - the running domain object
# Attaching the new interface d0:f:d0:f:2:1
ok 2 - interface has been attached
# xml contains mac address element (should be 1)
# 1
ok 3 - running domain has an ID > 0
# waiting for guests to boot
# PING 192.168.1.101 (192.168.1.101) 56(84) bytes of data.
# From 192.168.1.1 icmp_seq=2 Destination Host Unreachable
# From 192.168.1.1 icmp_seq=3 Destination Host Unreachable
# From 192.168.1.1 icmp_seq=4 Destination Host Unreachable
# From 192.168.1.1 icmp_seq=6 Destination Host Unreachable
# From 192.168.1.1 icmp_seq=7 Destination Host Unreachable
# From 192.168.1.1 icmp_seq=8 Destination Host Unreachable
# From 192.168.1.1 icmp_seq=9 Destination Host Unreachable
# From 192.168.1.1 icmp_seq=10 Destination Host Unreachable
# 
# --- 192.168.1.101 ping statistics ---
# 10 packets transmitted, 0 received, +8 errors, 100% packet loss, time
19000ms
# pipe 3
not ok 4 - ping 192.168.1.101 test

#   Failed test 'ping 192.168.1.101 test'
#
at /usr/share/libvirt-tck/tests/scripts/network/100-ping-still-working.t
line 82.
# cleaning up
# Detaching the 1st interface d0:f:d0:f:2:1
ok 5 - interface has been detached
# Looks like you failed 1 test of 5.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/5 subtests 

Test Summary Report
-------------------
/usr/share/libvirt-tck/tests/scripts/network/100-ping-still-working.t
(Wstat: 256 Tests: 5 Failed: 1)
  Failed test:  4
  Non-zero exit status: 1
Files=1, Tests=5, 30 wallclock secs ( 0.02 usr  0.02 sys +  0.24 cusr
0.13 csys =  0.41 CPU)
Result: FAIL


I see the following in the debug log:

...
qemuMonitorCommandWithHandler:216 : Send command 'getfd fd-tap.0' for
write with FD 18
...

For the working qemu:
qemuMonitorCommandWithHandler:221 : Receive command reply ret=0 errno=0
0 bytes '(null)'

For the failing qemu:
qemuMonitorCommandWithHandler:221 : Receive command reply ret=0 errno=0
44 bytes 'No file descriptor supplied via SCM_RIGHTS^M
'

Any ideas?

-- 
Best regards, 

Gerhard Stenzel, 
-----------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 100-ping-still-working.t
Type: text/troff
Size: 2258 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20100114/96f450ad/attachment-0001.t>


More information about the libvir-list mailing list