- Devel - libvirt List Archives

[libvirt] Storage pool/volume support in libvirt-gconfig
by Christophe Fergeau 15 Dec '11

15 Dec '11

Hi, This patch series adds configuration of storage pools and volumes to libvirt-gconfig. Nothing particularly exciting in there, just more gobjects and setters using the existing helpers. Maybe it would be worth introducing a gvir_config_object_set_content_with_attributes to factor some redundant code. Christophe

2 24

[libvirt] Transitioning from HMP to QMP for QEMU
by Stefan Hajnoczi 15 Dec '11

15 Dec '11

What is the status of QEMU's transition from HMP to the QMP interface? My current understanding is that QEMU provides new HMP commands for humans, but HMP is being phased out as an API. Management tools should rely only on QMP for new commands. That would mean new HMP commands are not guaranteed to produce backwards-compatible output because tools are not supposed to parse the output. On the libvirt side, new QEMU features should only be supported via the json monitor in the future (i.e. human monitor patches should not be sent/merged)? Existing HMP commands will still need the human monitor support in order to handle old QEMU versions gracefully, but I'm thinking about new commands only. Does everyone agree on this? I think this is an important discussion if we want our management interface to get better and more consistent in the future. Stefan

7 16

Re: [libvirt] FW: macvtap not working on rhel 6.1 x86 machine
by Amit Tewari 15 Dec '11

15 Dec '11

Hi, Can you please tell me what step iam missing? -----Original Message----- From: Gerhard Stenzel [mailto:gstenzel@linux.vnet.ibm.com] Sent: Thursday, December 15, 2011 5:03 PM To: Amit Tewari Cc: libvir-list(a)redhat.com Subject: RE: [libvirt] FW: macvtap not working on rhel 6.1 x86 machine On Thu, 2011-12-15 at 15:54 +0530, Amit Tewari wrote: > hi, > > i want the kvm guest machine to connect to network using macvtap.. > I tried this vepa mode it is also not working. where is your DHCP server? On the network or on your host? > eth0 has same mac address as that of macvatap0 that is 52:54:00:55:AE:B5 this is correct. The mac address of eth0 in the guest is the same as that of the macvtap device of the host. > due to this guest is not able to get dhcp address nor static ip address is working. it works for me. I am on 6.2 now, but this worked on 6.1 as well. -- 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 DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NECHCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NECHCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. . -----------------------------------------------------------------------------------------------------------------------

1 0

Re: [libvirt] FW: macvtap not working on rhel 6.1 x86 machine
by Amit Tewari 15 Dec '11

15 Dec '11

hi, i want the kvm guest machine to connect to network using macvtap.. I tried this vepa mode it is also not working. My test environment Host os=rhel6.1 Guest os = rhel6.1 Libvirt=0.8.7 Kvm hypervisor I have made this entry in guest xml file <interface type='direct'> <source dev='eth0' mode='bridge'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> Now when I start the guest #virsh start guest Following macvtap0 is created on host and is shown below #ip link show macvtap0 51: macvtap0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UNKNOWN qlen 500 link/ether 52:54:00:55:AE:B5brd ff:ff:ff:ff:ff:ff but when the guest is up and I try to perform # ifup eth0 eth0 has same mac address as that of macvatap0 that is 52:54:00:55:AE:B5 due to this guest is not able to get dhcp address nor static ip address is working. Please let me know how macvtap work on kvm. -----Original Message----- From: Gerhard Stenzel [mailto:gstenzel@linux.vnet.ibm.com] Sent: Thursday, December 15, 2011 3:47 PM To: Amit Tewari Cc: libvir-list(a)redhat.com Subject: Re: [libvirt] FW: macvtap not working on rhel 6.1 x86 machine On Thu, 2011-12-15 at 15:20 +0530, Amit Tewari wrote: > > > Hi all, > > > > My test environment > > Host os=rhel6.1 x86 machine > > Guest os = rhel6.1 > > Libvirt=0.8.7 > > Kvm hypervisor > Hi, maybe it would help if you try to explain first, what you are trying to achieve, what your setup looks like (including your DHCP setup and switch infrastructure). Here (http://libvirt.org/formatdomain.html) you will find the following xml sample, which works: ... <devices> <interface type='direct'> <source dev='eth0' mode='vepa'/> </interface> </devices> ... This will connect your VM directly to the same network as eth0. Please be aware that, depending on your switch configuration (supports hair pin mode or not), your host might not be able to talk to your VM and vice versa. -- 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 DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NECHCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NECHCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. . -----------------------------------------------------------------------------------------------------------------------

2 1

[libvirt] [PATCH] qemu: Fix race between async and query jobs
by Jiri Denemark 15 Dec '11

15 Dec '11

If an async job run on a domain will stop the domain at the end of the job, a concurrently run query job can hang in qemu monitor nothing can be done with that domain from this point on. An attempt to start such domain results in "Timed out during operation: cannot acquire state change lock" error. However, quite a few things have to happen at the right time... There must be an async job running, which stops a domain at the end. This race was with dump --crash but other similar jobs, such as (managed)save and migration, should be able to trigger this bug as well. While this async job is processing its last monitor command, that is a query-migrate to which qemu replies with status "completed", a new libvirt API that results in a query job must arrive and stay waiting until the query-migrate command finishes. Once query-migrate is done but before the async job closes qemu monitor while stopping the domain, the other thread needs to wake up and call qemuMonitorSend to send its command to qemu. Before qemu gets a chance to respond to this command, the async job needs to close the monitor. At this point, the query job thread is waiting for a condition that no-one will ever signal so it never finishes the job. --- src/qemu/qemu_monitor.c | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c index 4141fb7..35648ae 100644 --- a/src/qemu/qemu_monitor.c +++ b/src/qemu/qemu_monitor.c @@ -750,6 +750,20 @@ void qemuMonitorClose(qemuMonitorPtr mon) VIR_FORCE_CLOSE(mon->fd); } + /* In case another thread is waiting for its monitor command to be + * processed, we need to wake it up with appropriate error set. + */ + if (mon->msg) { + if (mon->lastError.code == VIR_ERR_OK) { + qemuReportError(VIR_ERR_OPERATION_FAILED, + _("Qemu monitor was closed")); + virCopyLastError(&mon->lastError); + virResetLastError(); + } + mon->msg->finished = 1; + virCondSignal(&mon->notify); + } + if (qemuMonitorUnref(mon) > 0) qemuMonitorUnlock(mon); } -- 1.7.8

2 2

[libvirt] FW: macvtap not working on rhel 6.1 x86 machine
by Amit Tewari 15 Dec '11

15 Dec '11

Hi all, My test environment Host os=rhel6.1 x86 machine Guest os = rhel6.1 Libvirt=0.8.7 Kvm hypervisor I am creating macvtap interface on host machine ip link add link eth1 name macvtap0 type macvtap ip link set macvtap0 up ip link show macvtap0 25: macvtap0@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500 link/ether a2:70:4e:05:4a:4e brd ff:ff:ff:ff:ff:ff Now when use arp -a to check macvtap0 hardware address entry it shows ? (10.0.7.1) at <incomplete> on macvtap0 If I assign ip address to macvtap and then ping on network , it says "destination not reachable" ping 10.0.7.1 -I macvtap0 PING 10.0.7.1 (10.0.7.1) from 10.0.1.61 macvtap0: 56(84) bytes of data. >From 10.0.1.61 icmp_seq=2 Destination Host Unreachable >From 10.0.1.61 icmp_seq=3 Destination Host Unreachable If I use tcpdump -I eth1 it shows packets 14:42:39.967158 ARP, Request who-has 10.0.7.1 tell 10.0.7.4, length 28 14:42:39.967257 ARP, Reply 10.0.7.1 is-at 00:16:35:65:b5:1e (oui Unknown), length 46 14:42:40.967167 ARP, Request who-has 10.0.7.1 tell 10.0.7.4, length 28 14:42:40.967229 ARP, Reply 10.0.7.1 is-at 00:16:35:65:b5:1e (oui Unknown), length 46 So macvtap0 is unknown interface. Request does go to eth1 inteface. Please let me know redhat 6.1 support macvtap or not?... I have to use it for kvm virtual machine.. DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NECHCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NECHCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. . -----------------------------------------------------------------------------------------------------------------------

2 1

[libvirt] [PATCH 0/4] Add new public API virDomainGetPcpusUsage and pcpuinfo command in virsh
by Lai Jiangshan 14 Dec '11

14 Dec '11

"virt-top -1" can call virDomainGetPcpusUsage() periodically and get the CPU activities per CPU. (still require virt-top site patch). virsh is also added a pcpuinfo command which calls virDomainGetPcpusUsage(), it gets information about the physic CPUs, such as the usage of CPUs, the current attached vCPUs. # virsh pcpuinfo rhel6 CPU: 0 Curr VCPU: - Usage: 47.3 CPU: 1 Curr VCPU: 1 Usage: 46.8 CPU: 2 Curr VCPU: 0 Usage: 52.7 CPU: 3 Curr VCPU: - Usage: 44.1 Lai Jiangshan (4): Add new public API virDomainGetPcpusUsage remote: support new API virDomainGetPcpusUsage for remote driver qemu: implemnt new API virDomainGetPcpusUsage for qemu driver Enable the pcpuinfo command in virsh daemon/remote.c | 68 ++++++++++++++++++++++++++++++ include/libvirt/libvirt.h.in | 5 ++ python/generator.py | 1 + src/driver.h | 7 +++ src/libvirt.c | 51 +++++++++++++++++++++++ src/libvirt_public.syms | 5 ++ src/qemu/qemu.conf | 5 +- src/qemu/qemu_conf.c | 3 +- src/qemu/qemu_driver.c | 74 +++++++++++++++++++++++++++++++++ src/remote/remote_driver.c | 51 +++++++++++++++++++++++ src/remote/remote_protocol.x | 17 +++++++- src/remote_protocol-structs | 13 ++++++ src/util/cgroup.c | 7 +++ src/util/cgroup.h | 1 + tools/virsh.c | 93 ++++++++++++++++++++++++++++++++++++++++++ tools/virsh.pod | 5 ++ 16 files changed, 402 insertions(+), 4 deletions(-) -- 1.7.4.4

2 7

Re: [libvirt] macvtap nt working on kvm
by Amit Tewari 14 Dec '11

14 Dec '11

Hi Stefan, May be you can try again this test of macvtap on your environment, but please remove the bridge from eth0. because macvtap doesent work with bridge setup. -----Original Message----- From: Amit Tewari Sent: Thursday, December 15, 2011 9:05 AM To: 'Laine Stump'; libvir-list(a)redhat.com Subject: RE: [libvirt] macvtap nt working on kvm Hi, Actually macvatap doesn't work with bridge. So once the physical device is attached to a bridge, a macvtap attached to that device no longer works. In my case there is no bridge on the interface. but still guest os is not able to get ip address. Is there no support for macvtap on red hat 6.1 x_86 platforms? -----Original Message----- From: libvir-list-bounces(a)redhat.com [mailto:libvir-list-bounces@redhat.com] On Behalf Of Laine Stump Sent: Thursday, December 15, 2011 2:31 AM To: libvir-list(a)redhat.com Subject: Re: [libvirt] macvtap nt working on kvm On 12/14/2011 02:26 PM, Stefan Berger wrote: > On 12/14/2011 07:40 AM, Amit Tewari wrote: >> >> Hi all, >> >> My test environment >> >> Host os=rhel6.1 >> >> Guest os = rhel6.1 >> >> Libvirt=0.8.7 >> >> Kvm hypervisor >> >> I have made this entry in guest xml file >> >> <interface type='direct'> >> >> <source dev='eth0' mode='bridge'/> >> >> <model type='virtio'/> >> >> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' >> function='0x0'/> >> >> </interface> >> >> Now when I start the guest >> >> *#virsh start guest* >> >> Following macvtap0 is created on host and is shown below >> >> #*ip link show macvtap0* >> >> 51: macvtap0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc >> mq state UNKNOWN qlen 500 >> >> link/ether 52:54:00:55:AE:B5brd ff:ff:ff:ff:ff:ff >> >> but when the guest is up and I try to perform >> >> ** >> >> *# ifup eth0* >> >> *eth0 has same mac address as that of macvatap0 that is >> 52:54:00:55:AE:B5* >> >> ** >> >> *due to this guest is not able to get dhcp address nor static ip >> address is working*. >> >> Please let me know how macvtap work on kvm. >> > > I have tried your setup on my machine with the following host > configuration: > > # brctl show > bridge name bridge id STP enabled interfaces > br0 8000.001a64d00016 no eth0 > virbr0 8000.000000000000 yes > > If I use the configuration as you have shown it doesn't work for me, > either. However, if I use > > <source dev='br0' mode='bridge'/> > > then it works as expected. Do you happen to have a similar > configuration on the host with the interface the macvtap device wants > to use as 'source' being bridged? Interesting. So you're saying that once the physical device is attached to a bridge, a macvtap attached to that device no longer works? That's useful to know :-) -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NECHCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NECHCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. . -----------------------------------------------------------------------------------------------------------------------

1 0

Re: [libvirt] macvtap nt working on kvm
by Amit Tewari 14 Dec '11

14 Dec '11

Hi, Actually macvatap doesn't work with bridge. So once the physical device is attached to a bridge, a macvtap attached to that device no longer works. In my case there is no bridge on the interface. but still guest os is not able to get ip address. Is there no support for macvtap on red hat 6.1 x_86 platforms? -----Original Message----- From: libvir-list-bounces(a)redhat.com [mailto:libvir-list-bounces@redhat.com] On Behalf Of Laine Stump Sent: Thursday, December 15, 2011 2:31 AM To: libvir-list(a)redhat.com Subject: Re: [libvirt] macvtap nt working on kvm On 12/14/2011 02:26 PM, Stefan Berger wrote: > On 12/14/2011 07:40 AM, Amit Tewari wrote: >> >> Hi all, >> >> My test environment >> >> Host os=rhel6.1 >> >> Guest os = rhel6.1 >> >> Libvirt=0.8.7 >> >> Kvm hypervisor >> >> I have made this entry in guest xml file >> >> <interface type='direct'> >> >> <source dev='eth0' mode='bridge'/> >> >> <model type='virtio'/> >> >> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' >> function='0x0'/> >> >> </interface> >> >> Now when I start the guest >> >> *#virsh start guest* >> >> Following macvtap0 is created on host and is shown below >> >> #*ip link show macvtap0* >> >> 51: macvtap0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc >> mq state UNKNOWN qlen 500 >> >> link/ether 52:54:00:55:AE:B5brd ff:ff:ff:ff:ff:ff >> >> but when the guest is up and I try to perform >> >> ** >> >> *# ifup eth0* >> >> *eth0 has same mac address as that of macvatap0 that is >> 52:54:00:55:AE:B5* >> >> ** >> >> *due to this guest is not able to get dhcp address nor static ip >> address is working*. >> >> Please let me know how macvtap work on kvm. >> > > I have tried your setup on my machine with the following host > configuration: > > # brctl show > bridge name bridge id STP enabled interfaces > br0 8000.001a64d00016 no eth0 > virbr0 8000.000000000000 yes > > If I use the configuration as you have shown it doesn't work for me, > either. However, if I use > > <source dev='br0' mode='bridge'/> > > then it works as expected. Do you happen to have a similar > configuration on the host with the interface the macvtap device wants > to use as 'source' being bridged? Interesting. So you're saying that once the physical device is attached to a bridge, a macvtap attached to that device no longer works? That's useful to know :-) -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NECHCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NECHCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. . -----------------------------------------------------------------------------------------------------------------------

1 0

[libvirt] [PATCH RESEND] qemu: Do not free the device from activePciHostdevs if it's in use
by Osier Yang 14 Dec '11

14 Dec '11

* src/qemu/qemu_hostdev.c (qemuDomainReAttachHostdevDevices): pciDeviceListFree(pcidevs) in the end free()s the device even if it's in use by other domain, which can cause rase. How to reproduce: <script> virsh nodedev-dettach pci_0000_00_19_0 virsh start test virsh attach-device test hostdev.xml virsh start test2 for i in {1..5}; do echo "[ -- ${i}th time --]" virsh nodedev-reattach pci_0000_00_19_0 done echo "clean up" virsh destroy test virsh nodedev-reattach pci_0000_00_19_0 </script> Device pci_0000_00_19_0 dettached Domain test started Device attached successfully error: Failed to start domain test2 error: Requested operation is not valid: PCI device 0000:00:19.0 is in use by domain test [ -- 1th time --] Device pci_0000_00_19_0 re-attached [ -- 2th time --] Device pci_0000_00_19_0 re-attached [ -- 3th time --] Device pci_0000_00_19_0 re-attached [ -- 4th time --] Device pci_0000_00_19_0 re-attached [ -- 5th time --] Device pci_0000_00_19_0 re-attached clean up Domain test destroyed Device pci_0000_00_19_0 re-attached The patch also fixes another problem, there won't be error like "qemuDomainReAttachHostdevDevices: Not reattaching active device 0000:00:19.0" in daemon log if some device is in active. As pciResetDevice and pciReattachDevice won't be called for the device anymore. This is sensiable as we already reported error when preparing the device if it's active. Blindly trying to pciResetDevice & pciReattachDevice on the device and getting an error is just redundant. --- src/qemu/qemu_hostdev.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/src/qemu/qemu_hostdev.c b/src/qemu/qemu_hostdev.c index 9137388..60401f0 100644 --- a/src/qemu/qemu_hostdev.c +++ b/src/qemu/qemu_hostdev.c @@ -414,8 +414,10 @@ void qemuDomainReAttachHostdevDevices(struct qemud_driver *driver, */ activeDev = pciDeviceListFind(driver->activePciHostdevs, dev); if (activeDev && - STRNEQ_NULLABLE(name, pciDeviceGetUsedBy(activeDev))) + STRNEQ_NULLABLE(name, pciDeviceGetUsedBy(activeDev))) { + pciDeviceListSteal(pcidevs, dev); continue; + } /* pciDeviceListFree() will take care of freeing the dev. */ pciDeviceListSteal(driver->activePciHostdevs, dev); -- 1.7.7.3

2 2