- Devel - libvirt List Archives

[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 15 Dec '11

15 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 15 Dec '11

15 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 15 Dec '11

15 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 15 Dec '11

15 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

[libvirt] [PATCH RESEND] qemu: Honor the original properties of PCI device when detaching
by Osier Yang 15 Dec '11

15 Dec '11

This patch fixes two problems: 1) The device will be reattached to host even if it's not managed, as there is a "pciDeviceSetManaged". 2) The device won't be reattached to host with original driver properly. As it doesn't honor the device original properties which are maintained by driver->activePciHostdevs. --- src/qemu/qemu_hotplug.c | 17 +++++++++-------- 1 files changed, 9 insertions(+), 8 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 96c0070..19e4a41 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -1960,6 +1960,7 @@ int qemuDomainDetachHostPciDevice(struct qemud_driver *driver, qemuDomainObjPrivatePtr priv = vm->privateData; int i, ret; pciDevice *pci; + pciDevice *activePci; for (i = 0 ; i < vm->def->nhostdevs ; i++) { if (vm->def->hostdevs[i]->mode != VIR_DOMAIN_HOSTDEV_MODE_SUBSYS || @@ -2019,16 +2020,16 @@ int qemuDomainDetachHostPciDevice(struct qemud_driver *driver, detach->source.subsys.u.pci.bus, detach->source.subsys.u.pci.slot, detach->source.subsys.u.pci.function); - if (!pci) - ret = -1; - else { - pciDeviceSetManaged(pci, detach->managed); - pciDeviceListDel(driver->activePciHostdevs, pci); - if (pciResetDevice(pci, driver->activePciHostdevs, NULL) < 0) + if (pci) { + activePci = pciDeviceListSteal(driver->activePciHostdevs, pci); + if (pciResetDevice(activePci, driver->activePciHostdevs, NULL)) + qemuReattachPciDevice(activePci, driver); + else ret = -1; - pciDeviceReAttachInit(pci); - qemuReattachPciDevice(pci, driver); pciFreeDevice(pci); + pciFreeDevice(activePci); + } else { + ret = -1; } if (qemuCapsGet(priv->qemuCaps, QEMU_CAPS_DEVICE) && -- 1.7.7.3

2 2

[libvirt] [PATCH 0/4] Add support for QEMU guest agent control
by Daniel P. Berrange 15 Dec '11

15 Dec '11

The QEMU guest agent "/usr/bin/qemu-ga" has some handy functions for controlling the guest, not least, shutdown/reboot and filesystem freeze/thaw. In Fedora 15/16 the semantics of the ACPI power button have been changed to suspend-to-RAM which breaks our current shutdown implementation. By adding support for the agent we gain a more predictable way to shutdown / reboot guests. NB: the code currently has the same "flaw" as the monitor, in so much as we wait forever for a guest agent reply. We need to add a timeout ability to the agent code

3 17

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

14 Dec '11

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. 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. . -----------------------------------------------------------------------------------------------------------------------

3 3

Re: [libvirt] libvirt support on QNX
by Chandrashekhar Jamadarkhani (cjamadar) 14 Dec '11

14 Dec '11

Config.h file is missing in qnx. What is the path to config.h in linux ? Build Error (pasted here for one file only) src/util/iptables.c:22:20: error: config.h: No such file or directory Thanks, Chandrashekhar -----Original Message----- From: Chandrashekhar Jamadarkhani (cjamadar) Sent: Wednesday, December 14, 2011 3:24 PM To: 'Daniel P. Berrange' Subject: RE: libvirt support on QNX Thanks Daniel ! We are using Jamfile instead of Makefile in our build environment. Let me check how can I build the same in our build environment. Thanks, Chandarshekhar -----Original Message----- From: Daniel P. Berrange [mailto:berrange@redhat.com] Sent: Wednesday, December 14, 2011 2:56 PM To: Chandrashekhar Jamadarkhani (cjamadar) Subject: Re: libvirt support on QNX On Wed, Dec 14, 2011 at 02:50:31PM +0530, Chandrashekhar Jamadarkhani (cjamadar) wrote: > Thanks Daniel. I should port only src/rpc to QNX or anything else I need to port to QNX ? You basically want to build with ./configure \ --enable-compile-warnings=error \ --without-xen \ --without-qemu \ --without-openvz \ --without-lxc \ --without-vbox \ --without-xenapi \ --without-esx \ --without-uml \ --without-sasl \ --without-avahi \ --without-polkit \ --without-python \ --without-libvirtd \ --without-phyp \ --without-hyperv \ --without-netcf \ --without-audit \ --without-dtrace And then fix whatever fails to build (if anything). This should only be stuff in src/util src/conf src/rpc src/remote Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

2 1

[libvirt] [PATCH 0/3] spec file fixes
by Eric Blake 14 Dec '11

14 Dec '11

Several spec file patches that I've noticed by comparing against open BZs and existing RPMs. Probably all worth including in 0.9.8, but I'm not comfortable pushing them without a review. Eric Blake (3): spec: always autoreconf when building rpm spec: add dmidecode as prereq spec: fix sanlock dependency libvirt.spec.in | 30 +++++++++++++++++++++--------- 1 files changed, 21 insertions(+), 9 deletions(-) -- 1.7.7.3

5 25