June 2015 - Devel - libvirt List Archives

[libvirt] [PATCH] remove redundant condition
by Ján Tomko 18 Jun '15

18 Jun '15

If the address type is SPAPRVIO, it will match the != NONE condition. --- src/qemu/qemu_command.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 3886b4f..078ecf7 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -2423,8 +2423,6 @@ qemuAssignDevicePCISlots(virDomainDefPtr def, def->controllers[i]->idx == 0) continue; - if (def->controllers[i]->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO) - continue; if (def->controllers[i]->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE) continue; -- 2.3.6

2 1

[libvirt] [PATCH] tests: Sort EXTRA_DIST in the Makefile
by Michal Privoznik 17 Jun '15

17 Jun '15

We tend to keep the folders in the EXTRA_DIST sorted alphabetically. However, we've failed sometimes and the list is not ordered anymore. Reorder it back. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- tests/Makefile.am | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index a1cca5c..8e3ab91 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -72,6 +72,7 @@ LDADDS = \ ../src/libvirt.la EXTRA_DIST = \ + .valgrind.supp \ bhyvexml2argvdata \ bhyvexml2xmloutdata \ capabilityschemadata \ @@ -93,12 +94,12 @@ EXTRA_DIST = \ lxcxml2xmldata \ lxcxml2xmloutdata \ networkschematest \ + networkxml2confdata \ + networkxml2firewalldata \ networkxml2xmlin \ networkxml2xmlout \ - networkxml2confdata \ networkxml2xmlupdatein \ networkxml2xmlupdateout \ - networkxml2firewalldata \ nodedevschemadata \ nodedevschematest \ nodeinfodata \ @@ -116,41 +117,40 @@ EXTRA_DIST = \ qemuxml2argvdata \ qemuxml2xmloutdata \ qemuxmlnsdata \ + schematestutils.sh \ secretxml2xmlin \ securityselinuxhelperdata \ securityselinuxlabeldata \ - schematestutils.sh \ sexpr2xmldata \ storagepoolschemadata \ storagepoolschematest \ storagepoolxml2xmlin \ storagepoolxml2xmlout \ - storagevolxml2argvdata \ storagevolschemadata \ storagevolschematest \ + storagevolxml2argvdata \ storagevolxml2xmlin \ storagevolxml2xmlout \ sysinfodata \ test-lib.sh \ - vircaps2xmldata \ vboxsnapshotxmldata \ - virsh-uriprecedence \ + vircaps2xmldata \ vircgroupdata \ virfiledata \ + virmock.h virnetdaemondata \ virnetdevtestdata \ virpcitestdata \ virscsidata \ + virsh-uriprecedence \ virusbtestdata \ + vmwareverdata \ vmx2xmldata \ xencapsdata \ - xmconfigdata \ xlconfigdata \ + xmconfigdata \ xml2sexprdata \ xml2vmxdata \ - vmwareverdata \ - .valgrind.supp \ - virmock.h test_helpers = commandhelper ssh test_conf test_programs = virshtest sockettest \ -- 2.3.6

2 1

[libvirt] [PATCH] daemon: Don't just include admin RPC
by Michal Privoznik 17 Jun '15

17 Jun '15

So, it's a little paradox that we use the file twice. Firstly to build libvirt-admin.la (a client side of the Admin API), then once again to build the server side. Well, the problem is, this does not play nicely with the distclean since the file is generated. So while it's removed in the src/ the distclean running in daemon/ will not find the file and fail. The file is needed because it contains the RPC wrappers. So let's leave the client code as is and from the daemon/ just link the client library. The linker will find desired symbols and use them. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- daemon/Makefile.am | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/daemon/Makefile.am b/daemon/Makefile.am index b9c089d..d3fc029 100644 --- a/daemon/Makefile.am +++ b/daemon/Makefile.am @@ -128,8 +128,7 @@ libvirtd_conf_la_LIBADD = $(LIBXML_LIBS) noinst_LTLIBRARIES += libvirtd_admin.la libvirtd_admin_la_SOURCES = \ - admin_server.c admin_server.h \ - ../src/admin/admin_protocol.c + admin_server.c admin_server.h libvirtd_admin_la_CFLAGS = \ $(AM_CFLAGS) \ @@ -145,6 +144,9 @@ libvirtd_admin_la_LDFLAGS = \ $(COVERAGE_LDFLAGS) \ $(NO_INDIRECT_LDFLAGS) +libvirtd_admin_la_LIBADD = \ + ../src/libvirt-admin.la + man8_MANS = libvirtd.8 sbin_PROGRAMS = libvirtd -- 2.3.6

2 1

[libvirt] nodedev-dumpxml doesn't refresh supported offload NIC capabilities
by Moshe Levi 17 Jun '15

17 Jun '15

Hi, I was playing with the nodedev-dumpxml to see the supported offload NIC capabilities, and It seem that if I disable one of offloading capabilities using ethtool command nodedev-dumpxml it still return the feature as enabled. To get the correct offloading capabilities I have to restart libvirtd. I was wandering if that is an expected behavior in lbivirt . Please see example below with the rx capabilities disabled. virsh # nodedev-dumpxml net_enp4s0_f4_52_14_11_73_81 <device> <name>net_enp4s0_f4_52_14_11_73_81</name> <path>/sys/devices/pci0000:00/0000:00:02.0/0000:04:00.0/net/enp4s0</path> <parent>pci_0000_04_00_0</parent> <capability type='net'> <interface>enp4s0</interface> <address>f4:52:14:11:73:81</address> <link speed='40000' state='up'/> <feature name='rx'/> <feature name='tx'/> <feature name='sg'/> <feature name='tso'/> <feature name='gso'/> <feature name='gro'/> <feature name='rxvlan'/> <feature name='txvlan'/> <feature name='rxhash'/> <capability type='80203'/> </capability> </device> ethtool -K enp4s0 rx off virsh # nodedev-dumpxml net_enp4s0_f4_52_14_11_73_81 <device> <name>net_enp4s0_f4_52_14_11_73_81</name> <path>/sys/devices/pci0000:00/0000:00:02.0/0000:04:00.0/net/enp4s0</path> <parent>pci_0000_04_00_0</parent> <capability type='net'> <interface>enp4s0</interface> <address>f4:52:14:11:73:81</address> <link speed='40000' state='up'/> <feature name='rx'/> <feature name='tx'/> <feature name='sg'/> <feature name='tso'/> <feature name='gso'/> <feature name='gro'/> <feature name='rxvlan'/> <feature name='txvlan'/> <feature name='rxhash'/> <capability type='80203'/> </capability> </device> virsh # [root@r-ae-host05 bin]# ps -ef | grep libvirt root 16743 23086 0 16:43 pts/2 00:00:00 ../sbin/libvirtd root 17440 23086 0 16:47 pts/2 00:00:00 grep --color=auto libvirt [root@r-ae-host05 bin]# kill 16743 [root@r-ae-host05 bin]# ../sbin/libvirtd & [2] 17489 [1] Done ../sbin/libvirtd [root@r-ae-host05 bin]# [root@r-ae-host05 bin]# [root@r-ae-host05 bin]# ./virsh virsh # nodedev-dumpxml net_enp4s0_f4_52_14_11_73_81 <device> <name>net_enp4s0_f4_52_14_11_73_81</name> <path>/sys/devices/pci0000:00/0000:00:02.0/0000:04:00.0/net/enp4s0</path> <parent>pci_0000_04_00_0</parent> <capability type='net'> <interface>enp4s0</interface> <address>f4:52:14:11:73:81</address> <link speed='40000' state='up'/> <feature name='tx'/> <feature name='sg'/> <feature name='tso'/> <feature name='gso'/> <feature name='gro'/> <feature name='rxvlan'/> <feature name='txvlan'/> <feature name='rxhash'/> <feature name='rdma'/> <capability type='80203'/> </capability> </device> Thanks, Moshe Levi.

2 3

[libvirt] [PATCH] nodedev: update netdev feature bits before each dumpxml
by Laine Stump 17 Jun '15

17 Jun '15

As with several other attributes of devices (link status, sriov VF list, IOMMU group list), the detdev feature bits aren't automatically updated in the nodedev driver's cache when they change. In order to get a properly up-to-date list when getting the XML of a device, we must reget them in update-caps prior to each dumpxml. Reported-By: Moshe Levi <moshele(a)mellanox.com> --- I dislike needing to put in the virBitmapFree and set the pointer to NULL before re-getting the features, but leaving it out would lead to a leak of the old bitmap, and I'm not sure I want virNetDevGetFeatures() to assume a valid pointer when it starts (it currently assumes the pointer contents is junk, and overwrites it with a newly allocated *virBitmap). src/node_device/node_device_driver.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/node_device/node_device_driver.c b/src/node_device/node_device_driver.c index 768db7f..31741b9 100644 --- a/src/node_device/node_device_driver.c +++ b/src/node_device/node_device_driver.c @@ -58,6 +58,10 @@ static int update_caps(virNodeDeviceObjPtr dev) case VIR_NODE_DEV_CAP_NET: if (virNetDevGetLinkInfo(cap->data.net.ifname, &cap->data.net.lnk) < 0) return -1; + virBitmapFree(cap->data.net.features); + cap->data.net.features = NULL; + if (virNetDevGetFeatures(cap->data.net.ifname, &cap->data.net.features) < 0) + return -1; break; case VIR_NODE_DEV_CAP_PCI_DEV: if (nodeDeviceSysfsGetPCIRelatedDevCaps(dev->def->sysfs_path, -- 2.1.0

2 2

[libvirt] VIRTIO v1.0 15-day public review - ends July 2nd
by Chet Ensign 17 Jun '15

17 Jun '15

OASIS members and other interested parties, The Virtual I/O Device (VIRTIO) TC members [1] have produced an updated Committee Specification Draft (CSD) and submitted this specification for 15-day public review: Virtual I/O Device (VIRTIO) Version 1.0 Committee Specification Draft 04 / Public Review Draft 04 28 May 2015 Specification overview: This document describes the specifications of the "virtio" family of devices. These devices are found in virtual environments, yet by design they are not all that different from physical devices, and this document treats them as such. This allows the guest to use standard drivers and discovery mechanisms. The purpose of virtio and this specification is that virtual environments and guests should have a straightforward, efficient, standard and extensible mechanism for virtual devices, rather than boutique per-environment or per-OS mechanisms. Among multiple other enhancements and corrections, the Virtio specification now includes support for the memory balloon device for managing guest memory. This puts Virtio 1.0 at feature parity with Virtio 0.9. This is the first public review of VIRTIO since it was approved as Committee Specification 02 (CS02). The files http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04-d… and http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04-d… include all changes since CS02 highlighted. TC Description: The goal of the OASIS Virtual I/O Device (VIRTIO) TC is to simplify virtual devices, making them more extensible and more recognizable. The purpose of VIRTIO is to ensure that virtual environments and guests have a straightforward, efficient, standard, and extensible mechanism for virtual devices, rather than boutique per-environment or per-OS mechanisms. Public Review Period: The public review starts 18 June 2015 at 00:00 UTC and ends 02 July 2015 at 23:59 UTC. This is the first public review of VIRTIO since it was approved as Committee Specification 02 (CS02). The files http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04-d… and http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04-d… include all changes since CS02 highlighted [2]. This 15-day review is limited in scope to these changes. This is an open invitation to comment. OASIS solicits feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of its technical work. Reviewers may provide comments directly from the comment-tag version of document. The file http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04-C… contains the HTML version of the draft with a “[comment?]” link next to each section heading. Clicking on this link will launch your email application and begin a message to virtio-comment(a)lists.oasis-open.org with the specific section number and title in the subject line. Simply enter your comment and click send. Note that you must be subscribed to the comment mailing list before sending feedback. Instructions on how to subscribe can be found at https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=virtio. URIs: The prose specification document and related files are available here: Editable source (Authoritative): http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/tex/ HTML: http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04.h… HTML with inline tags for direct commenting: http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04-C… PDF: http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04.p… ZIP distribution files (complete): For your convenience, OASIS provides a complete package of the prose specification and related files in a ZIP distribution file. You can download the ZIP file here: http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04.z… Additional information about this specification and the VIRTIO TC may be found on the TC's public home page located at: http://www.oasis-open.org/committees/virtio/ Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility which can be accessed via the button labeled "Send A Comment" at the top of the TC public home page, or directly at: http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=virtio Feedback submitted by TC non-members for this work and for other work of this TC is publicly archived and can be viewed at: http://lists.oasis-open.org/archives/virtio-comment/ All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. In connection with this public review of 'Virtual I/O Device (VIRTIO) Version 1.0', we call your attention to the OASIS IPR Policy [3] applicable especially [4] to the work of this technical committee. All members of the TC should be familiar with this document, which may create obligations regarding the disclosure and availability of a member's patent, copyright, trademark and license rights that read on an approved OASIS specification. OASIS invites any persons who know of any such claims to disclose these if they may be essential to the implementation of the above specification, so that notice of them may be posted to the notice page for this TC's work. ========== Additional references: [1] Virtual I/O Device (VIRTIO) TC http://www.oasis-open.org/committees/virtio/ [2] Redlined DIFF file: http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04-d… [3] http://www.oasis-open.org/policies-guidelines/ipr [4] http://www.oasis-open.org/committees/virtio/ipr.php https://www.oasis-open.org/policies-guidelines/ipr#licensing_req Non-Assertion Mode -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393

1 0

[libvirt] [PATCH 0/3] parallels: add statistiscs
by Nikolay Shirokovskiy 17 Jun '15

17 Jun '15

Add vz statistics for network, cpu and memory. src/vz/vz_driver.c | 133 +++++++++++++++++++++++++++++++++++++++++++++++++++- src/vz/vz_sdk.c | 69 ++++++++++++++++++++++++++- src/vz/vz_sdk.h | 4 ++

1 3

[libvirt] PING: [PATCH v2 0/2] Allow PCI virtio on ARM "virt" machine
by Pavel Fedin 17 Jun '15

17 Jun '15

Hello ? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia > -----Original Message----- > From: libvir-list-bounces(a)redhat.com [mailto:libvir-list-bounces@redhat.com] On Behalf Of > Pavel Fedin > Sent: Thursday, June 11, 2015 9:41 AM > To: libvir-list(a)redhat.com > Cc: Pavel Fedin > Subject: [libvirt] [PATCH v2 0/2] Allow PCI virtio on ARM "virt" machine > > Virt machine in qemu since v2.3.0 has PCI generic host controller, and can use > PCI devices. This provides performance improvement as well as vhost-net with > irqfd support for virtio-net. However libvirt still insists on virtio devices > attached to virt machine to have MMIO bindings. This patch allows to use both. > If the user doesn't specify <address type='virtio-mmio'>, PCI will be used by > default. > > Changes since v1: > - Added capability based on qemu version number > - Recognize also "virt-" prefix > > Pavel Fedin (2): > Introduce QEMU_CAPS_ARM_VIRT_PCI > Allow PCI virtio on ARM "virt" machine > > src/qemu/qemu_capabilities.c | 5 +++++ > src/qemu/qemu_capabilities.h | 1 + > src/qemu/qemu_command.c | 15 ++++++++++++--- > 3 files changed, 18 insertions(+), 3 deletions(-) > > -- > 1.9.5.msysgit.0 > > -- > libvir-list mailing list > libvir-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list

2 1

[libvirt] [PATCH 0/3] Fix yet again some Admin API bugs
by Michal Privoznik 17 Jun '15

17 Jun '15

Pushed under trivial and build-breaker rules. The 'make rpm' is broken. There is still one issue I'm chasing down. Running 'distcheck' shows some errors. Michal Privoznik (3): daemon: Distribute admin_server.h tests: Follow virnetserver to virnetdaemon transition libvirt.spec: Don't expect virt-admin in libvirt-admin yet daemon/Makefile.am | 2 +- libvirt.spec.in | 2 -- tests/Makefile.am | 2 +- 3 files changed, 2 insertions(+), 4 deletions(-) -- 2.3.6

1 3

[libvirt] PING: [PATCH v2 0/2] Allow PCI virtio on ARM "virt" machine
by Pavel Fedin 17 Jun '15

17 Jun '15

Knock-knock??? Sorry for possibly repeated PING, but i see that mailing list for some reason strips CC:'s if specified without real name, so retry with name this time. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia > -----Original Message----- > From: libvir-list-bounces(a)redhat.com [mailto:libvir-list-bounces@redhat.com] On Behalf Of > Pavel Fedin > Sent: Thursday, June 11, 2015 9:41 AM > To: libvir-list(a)redhat.com > Cc: Pavel Fedin > Subject: [libvirt] [PATCH v2 0/2] Allow PCI virtio on ARM "virt" machine > > Virt machine in qemu since v2.3.0 has PCI generic host controller, and can use > PCI devices. This provides performance improvement as well as vhost-net with > irqfd support for virtio-net. However libvirt still insists on virtio devices > attached to virt machine to have MMIO bindings. This patch allows to use both. > If the user doesn't specify <address type='virtio-mmio'>, PCI will be used by > default. > > Changes since v1: > - Added capability based on qemu version number > - Recognize also "virt-" prefix > > Pavel Fedin (2): > Introduce QEMU_CAPS_ARM_VIRT_PCI > Allow PCI virtio on ARM "virt" machine > > src/qemu/qemu_capabilities.c | 5 +++++ > src/qemu/qemu_capabilities.h | 1 + > src/qemu/qemu_command.c | 15 ++++++++++++--- > 3 files changed, 18 insertions(+), 3 deletions(-) > > -- > 1.9.5.msysgit.0 > > -- > libvir-list mailing list > libvir-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list

1 0