- Devel - libvirt List Archives

[libvirt] [PATCH] Allows for a <description> tag for domains
by Daniel Veillard 01 Oct '09

01 Oct '09

https://bugzilla.redhat.com/show_bug.cgi?id=523639 feature request which makes sense to me, the simple patch attached seems to be sufficient, one can define and have the description back in the dump. Doesn't try to keep the location of the tag, it always get serialized after <uuid>. The only drawbacks I can think of are: - others XML formats may require the same, but honnestly it's trivial - machine generated description (for example if the history log of a domain gets stored there) could grow a lot and I wonder if we have a hard limit on the size when transmitting xml descriptions Oh and I didn't found a good place to test the feature, i.e. no test seems to parse and reserialize XML it's always about conversions. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/

4 8

[libvirt] [PATCH] Avoid a libvirtd crash on broken input 523418
by Daniel Veillard 01 Oct '09

01 Oct '09

A simple typo in an XML domain file could lead to a crash, because we called STRPREFIX() on the looked up value without checking it was non-null. Patch is trivial, and should go in but I wonder if we shouldn't make those STR macros safer too like turning #define STRPREFIX(a,b) (strncmp((a),(b),strlen((b))) == 0) into #define STRPREFIX(a,b) ((a) && (b) && (strncmp((a),(b),strlen((b))) == 0)) anyway I think we should apply the patch independently, without it libvirtd crash, with it we get the proper error report: [root@paphio ~]# virsh define RHEL-5.4-64.xml 18:32:21.982: warning : processCallDispatchReply:7570 : Method call error error: Failed to define domain from RHEL-5.4-64.xml error: internal error No <source> 'dev' attribute specified with <interface type='bridge'/> Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/

2 2

[libvirt] [PATCH] Fix USB device re-labelling
by Mark McLoughlin 01 Oct '09

01 Oct '09

A simple misplaced break out of a switch results in: libvir: error : Failed to open file '/sys/bus/pci/devices/0000:00:54c./vendor': No such file or directory libvir: error : Failed to open file '/sys/bus/pci/devices/0000:00:54c./device': No such file or directory libvir: error : this function is not supported by the hypervisor: Failed to read product/vendor ID for 0000:00:54c. when trying to passthrough a USB host device to qemu. * src/security_selinux.c: fix a switch/break thinko --- src/security/security_selinux.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c index bdd9eb2..d08d502 100644 --- a/src/security/security_selinux.c +++ b/src/security/security_selinux.c @@ -492,12 +492,11 @@ SELinuxSetSecurityHostdevLabel(virConnectPtr conn, ret = usbDeviceFileIterate(conn, usb, SELinuxSetSecurityUSBLabel, vm); usbFreeDevice(conn, usb); - - break; } else { /* XXX deal with product/vendor better */ ret = 0; } + break; } case VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI: { -- 1.6.2.5

2 1

[libvirt] [OT] Relocation lookup
by Rakotomandimby Mihamina 01 Oct '09

01 Oct '09

Hi all, Given the Social and Political reality in my country (Madagascar), I am obliged to look for a relocation. This is my public profile: http://www.linkedin.com/in/mihaminarakotomandimby Would you be aware of a position I could fit in? Thank you. -- Architecte Informatique chez Blueline/Gulfsat: Administration Systeme, Recherche & Developpement +261 34 29 155 34

1 0

[libvirt] [PATCH] incorrect error message in virDomainNetDefParseXML
by Florian Vichot 01 Oct '09

01 Oct '09

When declaring a <interface type="bridge"> tag, <source> needs a "bridge" attribute, but the parser complains about a missing "dev" attribute. Florian

3 4

[libvirt] "virsh destroy" deletes extra VMs
by Shi Jin 30 Sep '09

30 Sep '09

Hi there, I am running Ubuntu 9.04 X64 server with KVM/libvirt. I recently found that the "virsh destroy" command actually delete VMs it should not delete. For example, please see the following screen copy: root@node1:/srv/cloud/ImgRep/WinXP# virsh list Connecting to uri: qemu:///system Id Name State ---------------------------------- 27 one-80 running 28 one-81 running 29 one-83 running 30 one-82 running 31 one-79 running root@node1:/srv/cloud/ImgRep/WinXP# virsh destroy 29 Connecting to uri: qemu:///system Domain 29 destroyed root@node1:/srv/cloud/ImgRep/WinXP# virsh list Connecting to uri: qemu:///system Id Name State ---------------------------------- 27 one-80 running 28 one-81 running 31 one-79 running Please note that VM 30 was deleted when we tried to delete VM 29. The /var/log/messages showed the following information: ep 30 08:58:59 node1 kernel: [238101.304619] br1: port 5(vnet4) entering disabled state Sep 30 08:58:59 node1 kernel: [238101.342851] device vnet4 left promiscuous mode Sep 30 08:58:59 node1 kernel: [238101.342854] br1: port 5(vnet4) entering disabled state Sep 30 08:58:59 node1 kernel: [238101.424851] br1: port 4(vnet3) entering disabled state Sep 30 08:59:00 node1 kernel: [238101.463031] device vnet3 left promiscuous mode Sep 30 08:59:00 node1 kernel: [238101.463035] br1: port 4(vnet3) entering disabled state Sep 30 09:10:53 node1 -- MARK -- Sep 30 09:30:53 node1 -- MARK -- Sep 30 09:50:53 node1 -- MARK -- Sep 30 09:51:31 node1 kernel: [241253.266955] device vnet3 entered promiscuous mode Sep 30 09:51:31 node1 kernel: [241253.268857] br1: port 4(vnet3) entering learning state Sep 30 09:51:40 node1 kernel: [241262.260147] br1: topology change detected, propagating Sep 30 09:51:40 node1 kernel: [241262.260152] br1: port 4(vnet3) entering forwarding state Sep 30 09:53:59 node1 kernel: [241401.204570] br1: port 4(vnet3) entering disabled state Sep 30 09:53:59 node1 kernel: [241401.232395] device vnet3 left promiscuous mode Sep 30 09:53:59 node1 kernel: [241401.232399] br1: port 4(vnet3) entering disabled state Sep 30 09:54:20 node1 kernel: [241421.694803] br1: port 2(vnet0) entering disabled state Sep 30 09:54:20 node1 kernel: [241421.733095] device vnet0 left promiscuous mode Sep 30 09:54:20 node1 kernel: [241421.733099] br1: port 2(vnet0) entering disabled state Sep 30 09:54:20 node1 kernel: [241421.815209] br2: port 2(vnet1) entering disabled state Sep 30 09:54:20 node1 kernel: [241421.853728] device vnet1 left promiscuous mode Sep 30 09:54:20 node1 kernel: [241421.853732] br2: port 2(vnet1) entering disabled state Sep 30 09:54:20 node1 kernel: [241421.935254] br1: port 3(vnet2) entering disabled state Sep 30 09:54:20 node1 kernel: [241421.963527] device vnet2 left promiscuous mode Sep 30 09:54:20 node1 kernel: [241421.963531] br1: port 3(vnet2) entering disabled state Sep 30 09:55:29 node1 kernel: [241490.644204] br1: port 6(vnet5) entering disabled state Sep 30 09:55:29 node1 kernel: [241490.673195] device vnet5 left promiscuous mode Sep 30 09:55:29 node1 kernel: [241490.673199] br1: port 6(vnet5) entering disabled state Sep 30 10:10:53 node1 -- MARK -- Sep 30 10:11:49 node1 kernel: [242470.955142] device vnet0 entered promiscuous mode Sep 30 10:11:49 node1 kernel: [242470.957051] br1: port 2(vnet0) entering learning state Sep 30 10:11:52 node1 kernel: [242474.180036] device vnet1 entered promiscuous mode Sep 30 10:11:52 node1 kernel: [242474.181943] br1: port 3(vnet1) entering learning state Sep 30 10:11:55 node1 kernel: [242477.431693] device vnet2 entered promiscuous mode Sep 30 10:11:55 node1 kernel: [242477.433558] br1: port 4(vnet2) entering learning state Sep 30 10:11:58 node1 kernel: [242479.950082] br1: topology change detected, propagating Sep 30 10:11:58 node1 kernel: [242479.950086] br1: port 2(vnet0) entering forwarding state Sep 30 10:12:00 node1 kernel: [242482.059146] device vnet3 entered promiscuous mode Sep 30 10:12:00 node1 kernel: [242482.060330] br1: port 5(vnet3) entering learning state Sep 30 10:12:01 node1 kernel: [242483.180170] br1: topology change detected, propagating Sep 30 10:12:01 node1 kernel: [242483.180173] br1: port 3(vnet1) entering forwarding state Sep 30 10:12:04 node1 kernel: [242485.710948] device vnet4 entered promiscuous mode Sep 30 10:12:04 node1 kernel: [242485.712109] br1: port 6(vnet4) entering learning state Sep 30 10:12:04 node1 kernel: [242486.430098] br1: topology change detected, propagating Sep 30 10:12:04 node1 kernel: [242486.430104] br1: port 4(vnet2) entering forwarding state Sep 30 10:12:09 node1 kernel: [242491.051857] br1: topology change detected, propagating Sep 30 10:12:09 node1 kernel: [242491.051862] br1: port 5(vnet3) entering forwarding state Sep 30 10:12:13 node1 kernel: [242494.711792] br1: topology change detected, propagating Sep 30 10:12:13 node1 kernel: [242494.711797] br1: port 6(vnet4) entering forwarding state Sep 30 10:22:00 node1 kernel: [243082.274008] br1: port 4(vnet2) entering disabled state Sep 30 10:22:00 node1 kernel: [243082.312108] device vnet2 left promiscuous mode Sep 30 10:22:00 node1 kernel: [243082.312112] br1: port 4(vnet2) entering disabled state Sep 30 10:22:00 node1 kernel: [243082.365331] br1: port 5(vnet3) entering disabled state Sep 30 10:22:00 node1 kernel: [243082.393430] device vnet3 left promiscuous mode Sep 30 10:22:00 node1 kernel: [243082.393433] br1: port 5(vnet3) entering disabled state I have 4 NICs and the ifconfig shows root@node1:/srv/cloud/ImgRep/WinXP# ifconfig bond0 Link encap:Ethernet HWaddr 00:24:e8:6b:0d:57 inet6 addr: fe80::224:e8ff:fe6b:d57/64 Scope:Link UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:7799931 errors:0 dropped:0 overruns:0 frame:0 TX packets:6879357 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:4360166425 (4.3 GB) TX bytes:4350243659 (4.3 GB) br0 Link encap:Ethernet HWaddr 00:24:e8:6b:0d:57 inet addr:192.168.1.128 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::224:e8ff:fe6b:d57/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:7641913 errors:0 dropped:0 overruns:0 frame:0 TX packets:6412260 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:4169876739 (4.1 GB) TX bytes:4291182908 (4.2 GB) br1 Link encap:Ethernet HWaddr 00:24:e8:6b:0d:5b inet6 addr: fe80::224:e8ff:fe6b:d5b/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:152606 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:11276026 (11.2 MB) TX bytes:468 (468.0 B) br2 Link encap:Ethernet HWaddr 00:24:e8:6b:0d:5d inet6 addr: fe80::224:e8ff:fe6b:d5d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:152596 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:11286132 (11.2 MB) TX bytes:468 (468.0 B) eth0 Link encap:Ethernet HWaddr 00:24:e8:6b:0d:57 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:3622205 errors:0 dropped:0 overruns:0 frame:0 TX packets:3443103 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1758147112 (1.7 GB) TX bytes:2174389369 (2.1 GB) Interrupt:36 Memory:d6000000-d6012700 eth1 Link encap:Ethernet HWaddr 00:24:e8:6b:0d:57 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:4177726 errors:0 dropped:0 overruns:0 frame:0 TX packets:3436254 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2602019313 (2.6 GB) TX bytes:2175854290 (2.1 GB) Interrupt:48 Memory:d8000000-d8012700 eth2 Link encap:Ethernet HWaddr 00:24:e8:6b:0d:5b inet6 addr: fe80::224:e8ff:fe6b:d5b/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:256014 errors:0 dropped:0 overruns:0 frame:0 TX packets:91549 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:20680139 (20.6 MB) TX bytes:17317087 (17.3 MB) Interrupt:32 Memory:da000000-da012700 eth3 Link encap:Ethernet HWaddr 00:24:e8:6b:0d:5d inet6 addr: fe80::224:e8ff:fe6b:d5d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:245189 errors:0 dropped:0 overruns:0 frame:0 TX packets:32669 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:20866257 (20.8 MB) TX bytes:8265329 (8.2 MB) Interrupt:42 Memory:dc000000-dc012700 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:324787 errors:0 dropped:0 overruns:0 frame:0 TX packets:324787 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:571707504 (571.7 MB) TX bytes:571707504 (571.7 MB) vnet0 Link encap:Ethernet HWaddr 52:c3:a3:d0:09:84 inet6 addr: fe80::50c3:a3ff:fed0:984/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:72 errors:0 dropped:0 overruns:0 frame:0 TX packets:533 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:10410 (10.4 KB) TX bytes:49306 (49.3 KB) vnet1 Link encap:Ethernet HWaddr 02:0d:4c:1e:5c:82 inet6 addr: fe80::d:4cff:fe1e:5c82/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:36 errors:0 dropped:0 overruns:0 frame:0 TX packets:563 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:6023 (6.0 KB) TX bytes:53245 (53.2 KB) vnet4 Link encap:Ethernet HWaddr a6:58:67:2b:37:8a inet6 addr: fe80::a458:67ff:fe2b:378a/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:42 errors:0 dropped:0 overruns:0 frame:0 TX packets:552 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:6733 (6.7 KB) TX bytes:52189 (52.1 KB) Note that there is no IP address assigned to the br1 device which is used here. I don't think that should be a problem. Also the first 2 NICs are bonded first and then created as a bridge br0 and I don't think it is a problem either. root@node1:/srv/cloud/ImgRep/WinXP# virsh --version Connecting to uri: qemu:///system 0.6.1 root@node1:/srv/cloud/ImgRep/WinXP# kvm -h QEMU PC emulator version 0.9.1 (kvm-84), Copyright (c) 2003-2008 Fabrice Bellard Has anyone had similar problem before? How can I fix it? Thanks a lot. Shi -- Shi Jin, PhD

2 2

[libvirt] [PATCH] fixes to allow 'make rpm' to work again
by Daniel Veillard 30 Sep '09

30 Sep '09

Just a few oversights: - examples/domain-events has no makefile, but domain-events/events-c does - we should still add examples/domain-events/events-python to the tarballs in make dist - python/libvirtclass.txt seems to have vanished from dist and builds not a big deal but don't assume it's there in the spec file. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/

2 3

[libvirt] [PATCH] Fix emission of domain events messages
by Daniel P. Berrange 30 Sep '09

30 Sep '09

The code which updated the message length after writing the payload wrote the updated length word in the wrong place since the XDR object was given a buffer pointing to the start of the header payload, rather than message start. * daemon/remote.c: Fix updating of event message length so that we actually send the payload, not just the header --- daemon/remote.c | 14 ++++++++------ 1 files changed, 8 insertions(+), 6 deletions(-) diff --git a/daemon/remote.c b/daemon/remote.c index 6d4cc1c..2b58045 100644 --- a/daemon/remote.c +++ b/daemon/remote.c @@ -4559,17 +4559,19 @@ remoteDispatchDomainEventSend (struct qemud_client *client, /* Serialise the return header and event. */ xdrmem_create (&xdr, - msg->buffer + msg->bufferOffset, - msg->bufferLength - msg->bufferOffset, + msg->buffer, + msg->bufferLength, XDR_ENCODE); - if (!xdr_remote_domain_event_msg(&xdr, data)) + /* Skip over the header we just wrote */ + if (xdr_setpos (&xdr, msg->bufferOffset) == 0) goto xdr_error; + if (!xdr_remote_domain_event_msg(&xdr, data)) + goto xdr_error; - /* Update length word */ - msg->bufferOffset += xdr_getpos (&xdr); - len = msg->bufferOffset; + /* Update length word to include payload*/ + len = msg->bufferOffset = xdr_getpos (&xdr); if (xdr_setpos (&xdr, 0) == 0) goto xdr_error; -- 1.6.2.5

2 3

[libvirt] Tunnelled migration
by Chris Lalancette 30 Sep '09

30 Sep '09

At long last, now that the stream stuff is committed to the tree, I can repost the tunnelled migration patches. Note that these patches will conflict in some places with danpb's previously posted "PEER2PEER" patches, but it should be easy to resolve the differences.

2 15

[libvirt] Fix apibuild.py warnings
by Matthias Bolte 30 Sep '09

30 Sep '09

apibuild.py warns about misformatted function comment for virStreamEventAddCallback, virStreamEventUpdateCallback and virStreamEventRemoveCallback. The attached patch adds the missing ':' and contains the resulting changes in docs/libvirt-api.xml and docs/libvirt-refs.xml Matthias

3 2