- Devel - libvirt List Archives

[libvirt] [PATCH] m4: bhyve: Fix check for the required bhyve programs
by Peter Krempa 09 Jun '14

09 Jun '14

bhyveload and bhyvectl wouldn't be checked otherwise as the configure script wouldn't execute one of the tests: checking for bhyve... /usr/local/sbin/bhyve checking for bhyvectl... /usr/local/sbin/bhyvectl checking for bhyveload... /usr/local/sbin/bhyveload ./configure: line 62602: test: too many arguments Fix the shell statement testing the 3 binaries. --- m4/virt-driver-bhyve.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/m4/virt-driver-bhyve.m4 b/m4/virt-driver-bhyve.m4 index 9c0030b..c65b15d 100644 --- a/m4/virt-driver-bhyve.m4 +++ b/m4/virt-driver-bhyve.m4 @@ -28,7 +28,7 @@ AC_DEFUN([LIBVIRT_DRIVER_CHECK_BHYVE],[ AC_PATH_PROG([BHYVECTL], [bhyvectl], [], [$PATH:/usr/sbin]) AC_PATH_PROG([BHYVELOAD], [bhyveload], [], [$PATH:/usr/sbin/]) - if test -z "$BHYVE" || test -z "$BHYVECTL" \ + if test -z "$BHYVE" || test -z "$BHYVECTL" || \ test -z "$BHYVELOAD" || test "$with_freebsd" = "no"; then if test "$with_bhyve" = "check"; then with_bhyve="no" -- 1.9.3

2 2

[libvirt] [PATCH] vmx: Relax virtualHW.version check
by Matthias Bolte 07 Jun '14

07 Jun '14

The original implementation of the VMX config parser assumed that the virtualHW.version would have more influence on the content of the VMX file than it actually seems to have. It started with accepting only version 4. Additonal versions were added later without any additional changes in the parser itself. This suggests that the influence of the virtualHW.version on the content and format of the VMX file is small or non-existent. The parser worked without any changes across several virtualHW and vSphere versions. So instead of adding new virtualHW.version values to the parser as they come along, or adding an extra flag to allow unknown virtualHW.version values just relax the check to require version 4 or later. --- This patch is meant as a alternative for this patch series: https://www.redhat.com/archives/libvir-list/2014-May/msg00122.html src/vmx/vmx.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/src/vmx/vmx.c b/src/vmx/vmx.c index 169440c..ce228d4 100644 --- a/src/vmx/vmx.c +++ b/src/vmx/vmx.c @@ -1316,12 +1316,10 @@ virVMXParseConfig(virVMXContext *ctx, goto cleanup; } - if (virtualHW_version != 4 && virtualHW_version != 7 && - virtualHW_version != 8 && virtualHW_version != 9 && - virtualHW_version != 10) { + if (virtualHW_version < 4) { virReportError(VIR_ERR_INTERNAL_ERROR, _("Expecting VMX entry 'virtualHW.version' to be " - "4, 7, 8, 9 or 10 but found %lld"), + "4 or higher but found %lld"), virtualHW_version); goto cleanup; } -- 1.8.1.2

2 2

[libvirt] QMP fallback race in libvirt
by Ron 07 Jun '14

07 Jun '14

Hi, Eric asked me to move this here from #virt so it doesn't get forgotten. I hit a weird bug in a new install of libvirt on Debian Jessie this week where a vm could not be configured to use any CPU type except passthrough. After much digging and headscratching, the immediate cause for that turns out to be one of the (three) files in the qemu/capabilities cache being generated wrongly the first time that libvirtd was started. Instead of being generated from the QMP queries, it appears to have fallen back to the old method of scraping 'qemu -cpu help', and since the output of that changed with qemu 2.0 it leads to things like: <cpu name='SandyBridge Intel Xeon E312xx (Sandy Bridge) '/> and hilarity then ensues when cpuModelIsAllowed() is called by x86Decode(). Since only one of the cache files there was corrupted like this, it would appear libvirt either didn't wait long enough, or didn't try hard enough, to get a connection to the monitor for the QMP query on what was probably also the very first time qemu had been started on this host machine. After nuking the cache files and restarting libvirtd they were then correctly regenerated, and things began to work as expected. This was all done on a new clean install of the host machine, so there was nothing around from any earlier versions to get tangled up with, and possibly means qemu had some first time init of its own to do which took some time before it was ready to be queried. I am also seeing bursts of several of these warnings in the logs: libvirtd[26475]: This thread seems to be the async job owner; entering monitor without asking for a nested job is dangerous Which I haven't confirmed as being related, but doesn't seem to be obviously unrelated either, and at worst is a separate bug. Cheers, Ron

1 0

[libvirt] libvirt, libxl and <channels>
by Dave Scott 06 Jun '14

06 Jun '14

Hi, Two of the applications I’d like to use with libvirt (cloudstack and oVirt) make use of “<channels>” in the domain XML, like this: <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/s-4-VM.agent'/> <target type='virtio' name='s-4-VM.vport'/> <address type='virtio-serial'/> </channel> I don’t believe these are currently supported by libvirt + libxl — I’d like to see what it would take to hook these up. I chatted with Daniel Berrange at the Xen hackathon last week, and if I understood correctly these channels are analogous to serial ports used for low-bandwidth communication to (e.g.) guest agents. Daniel suggested that the xen console mechanism ought to be adequate to power these things. The other option (if higher bandwidth was required) would be to use the Xen vchan protocol. I think the behaviour is: * bind a unix domain socket on the host (‘/var/lib/libvirt/qemu/…') * connect a bidirectional low-bandwidth channel to the guest * manifest the channel in the guest as a ‘/dev/vport/s-4-VM.vport’ device (?) So an application on the host can connect() to the host socket, an application in the guest can open() the guest device and they can talk privately. [Have I got this right?] I had a quick read of the libxl code and I think the consoles are considered an internal detail: there is a function libxl_console_get_tty to retrieve a console’s endpoint in dom0 but I couldn’t see a way to request additional consoles are created. The libxl_domain_config has disks, nics, pcidevs, vfbs, vkbs, and vtpms but no consoles. (Have I missed something?) Bypassing libxl I was able to manually create a /local/domain/%d/device/console/1 which was recognised by the VM as /dev/hvc1. As an aside, I notice that there are 2 console backends now: xenconsoled seems to only watch for the initial console, while a per-domain qemu process is used for all subsequent consoles, so any enhancements to the dom0 end would have to go into qemu? So to implement channels via consoles I would need to: 1. check if qemu when acting as a console server in dom0 is able to connect the console to a suitably named Unix domain socket in dom0 (signalled via xenstore in the usual way) 2. modify libxl to support consoles as configurable devices alongside disks, nics etc 3. add support to libvirt’s libxl driver 4. see if I can write something like a udev rule in the guest to notice the console, look up the ‘name’ from xenstore and make a suitably-named file? What do you think? Cheers, Dave

2 2

[libvirt] [PATCH] Fix virbitmaptest on 32-bit
by Ján Tomko 06 Jun '14

06 Jun '14

My commit 7d8afc4 was passing the incorrect size to virBitmapDataToString in the newly added test. --- Pushed as a trivial paper-bag build breaker fix. tests/virbitmaptest.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/virbitmaptest.c b/tests/virbitmaptest.c index 139b8e2..048946f 100644 --- a/tests/virbitmaptest.c +++ b/tests/virbitmaptest.c @@ -313,7 +313,7 @@ test5(const void *v ATTRIBUTE_UNUSED) if (STRNEQ(str, "0,9,34")) goto error; VIR_FREE(str); - if (!(str = virBitmapDataToString(data2, sizeof(data2)))) + if (!(str = virBitmapDataToString(data2, len2))) goto error; if (STRNEQ(str, "0,2,9,15,34")) goto error; -- 1.8.3.2

1 0

[libvirt] [PATCH] nodedev: Export NUMA node locality for PCI devices
by Michal Privoznik 06 Jun '14

06 Jun '14

A PCI device can be associated with a specific NUMA node. Later, when a guest is pinned to one NUMA node the PCI device can be assigned on different NUMA node. This makes DMA transfers travel across nodes and thus results in suboptimal performance. We should expose the NUMA node locality for PCI devices so management applications can make better decisions. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- The only difference to the previous round is, I'm sending it as standalone patch for easier review. docs/formatnode.html.in | 7 ++++ docs/schemas/nodedev.rng | 10 +++++ src/conf/node_device_conf.c | 44 ++++++++++++++++++++++ src/conf/node_device_conf.h | 1 + src/node_device/node_device_udev.c | 7 ++++ tests/nodedevschemadata/pci_1002_71c4.xml | 1 + tests/nodedevschemadata/pci_8086_10c9_sriov_pf.xml | 1 + 7 files changed, 71 insertions(+) diff --git a/docs/formatnode.html.in b/docs/formatnode.html.in index b424c96..76bf8af 100644 --- a/docs/formatnode.html.in +++ b/docs/formatnode.html.in @@ -110,6 +110,13 @@ have a list of <code>address</code> subelements, one for each VF on this PF. </dd> + <dt><code>numa</code></dt> + <dd> + This optional element contains information on the PCI device + with respect to NUMA. For example, the optional + <code>node</code> attribute tells which NUMA node is the PCI + device associated with. + </dd> </dl> </dd> <dt><code>usb_device</code></dt> diff --git a/docs/schemas/nodedev.rng b/docs/schemas/nodedev.rng index 81ab4d4..02d4106 100644 --- a/docs/schemas/nodedev.rng +++ b/docs/schemas/nodedev.rng @@ -158,6 +158,16 @@ </element> </optional> + <optional> + <element name='numa'> + <optional> + <attribute name='node'> + <data type='int'/> + </attribute> + </optional> + </element> + </optional> + </define> <define name='capusbdev'> diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c index e65b5e4..99fa448 100644 --- a/src/conf/node_device_conf.c +++ b/src/conf/node_device_conf.c @@ -346,6 +346,9 @@ char *virNodeDeviceDefFormat(const virNodeDeviceDef *def) virBufferAdjustIndent(&buf, -2); virBufferAddLit(&buf, "</iommuGroup>\n"); } + if (data->pci_dev.numa_node >= 0) + virBufferAsprintf(&buf, "<numa node='%d'/>\n", + data->pci_dev.numa_node); break; case VIR_NODE_DEV_CAP_USB_DEV: virBufferAsprintf(&buf, "<bus>%d</bus>\n", data->usb_dev.bus); @@ -520,6 +523,41 @@ char *virNodeDeviceDefFormat(const virNodeDeviceDef *def) return NULL; } +/** + * virNodeDevCapsDefParseIntOptional: + * @xpath: XPath to evaluate + * @ctxt: Context + * @value: Where to store parsed value + * @def: Node device which is parsed + * @invalid_error_fmt: error message to print on invalid format + * + * Returns: -1 on error (invalid int format under @xpath) + * 0 if @xpath was not found (@value is untouched) + * 1 on success + */ +static int +virNodeDevCapsDefParseIntOptional(const char *xpath, + xmlXPathContextPtr ctxt, + int *value, + virNodeDeviceDefPtr def, + const char *invalid_error_fmt) +{ + int ret; + int val; + + ret = virXPathInt(xpath, ctxt, &val); + if (ret < -1) { + virReportError(VIR_ERR_INTERNAL_ERROR, + invalid_error_fmt, + def->name); + return -1; + } else if (ret == -1) { + return 0; + } + *value = val; + return 1; +} + static int virNodeDevCapsDefParseULong(const char *xpath, xmlXPathContextPtr ctxt, @@ -1101,6 +1139,12 @@ virNodeDevCapPCIDevParseXML(xmlXPathContextPtr ctxt, goto out; } } + + if (virNodeDevCapsDefParseIntOptional("number(./numa[1]/@node)", ctxt, + &data->pci_dev.numa_node, def, + _("invalid NUMA node ID supplied for '%s'")) < 0) + goto out; + ret = 0; out: ctxt->node = orignode; diff --git a/src/conf/node_device_conf.h b/src/conf/node_device_conf.h index 50e6805..50ce4b3 100644 --- a/src/conf/node_device_conf.h +++ b/src/conf/node_device_conf.h @@ -115,6 +115,7 @@ struct _virNodeDevCapsDef { virPCIDeviceAddressPtr *iommuGroupDevices; size_t nIommuGroupDevices; unsigned int iommuGroupNumber; + int numa_node; } pci_dev; struct { unsigned int bus; diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 9a951d9..8e98ad2 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -493,6 +493,13 @@ static int udevProcessPCI(struct udev_device *device, goto out; } + if (udevGetIntSysfsAttr(device, + "numa_node", + &data->pci_dev.numa_node, + 10) == PROPERTY_ERROR) { + goto out; + } + if (!virPCIGetPhysicalFunction(syspath, &data->pci_dev.physical_function)) data->pci_dev.flags |= VIR_NODE_DEV_CAP_FLAG_PCI_PHYSICAL_FUNCTION; diff --git a/tests/nodedevschemadata/pci_1002_71c4.xml b/tests/nodedevschemadata/pci_1002_71c4.xml index 6de09c1..6d5d85b 100644 --- a/tests/nodedevschemadata/pci_1002_71c4.xml +++ b/tests/nodedevschemadata/pci_1002_71c4.xml @@ -8,5 +8,6 @@ <function>0</function> <product id='0x71c4'>M56GL [Mobility FireGL V5200]</product> <vendor id='0x1002'>ATI Technologies Inc</vendor> + <numa node='1'/> </capability> </device> diff --git a/tests/nodedevschemadata/pci_8086_10c9_sriov_pf.xml b/tests/nodedevschemadata/pci_8086_10c9_sriov_pf.xml index eff8932..6e1dc86 100644 --- a/tests/nodedevschemadata/pci_8086_10c9_sriov_pf.xml +++ b/tests/nodedevschemadata/pci_8086_10c9_sriov_pf.xml @@ -12,5 +12,6 @@ <address domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> <address domain='0x0000' bus='0x02' slot='0x00' function='0x1'/> </iommuGroup> + <numa node='0'/> </capability> </device> -- 2.0.0

2 2

[libvirt] [PATCH 0/6] Print cpu maps in human readable form
by Ján Tomko 06 Jun '14

06 Jun '14

Consistently report errors in virBitmapFormat and introduce a flag for vcpuinfo and nodecpumap for more readable cpu map outputs. Ján Tomko (6): Invert logic in cmdVcpuinfo Separate API calls and result printing in cmdVcpuinfo Format NULL bitmap as an empty string Always report an error if virBitmapFormat fails Introudce virBitmapDataToString Implement pretty flag for vcpuinfo and nodecpumap src/conf/capabilities.c | 4 +- src/conf/domain_conf.c | 19 ++-------- src/conf/network_conf.c | 2 +- src/libvirt_private.syms | 1 + src/libxl/libxl_driver.c | 3 +- src/lxc/lxc_cgroup.c | 11 +----- src/qemu/qemu_cgroup.c | 16 ++------ src/qemu/qemu_driver.c | 12 ++---- src/util/virbitmap.c | 32 +++++++++++++--- src/util/virbitmap.h | 7 +++- src/util/virstring.h | 1 - tests/virbitmaptest.c | 14 ++++++- tools/virsh-domain.c | 97 +++++++++++++++++++++++++----------------------- tools/virsh-host.c | 25 +++++++++++-- 14 files changed, 134 insertions(+), 110 deletions(-) -- 1.8.3.2

3 19

[libvirt] [PATCH 0/3] Parallels: patch set
by Alexander Burluka 06 Jun '14

06 Jun '14

From: A.Burluka <aburluka(a)parallels.com> I've fixed my previous patches after Libvirt community reviews (thanks to Eric Blake and Daniel P. Berrange). Parallels team continues working on Libvirt Parallels driver integration with OpenStack. A.Burluka (3): Parallels: add domainGetVcpus(). Parallels: add connectBaselineCPU(). Parallels: Include CPU info in the capabilities XML

4 9

[libvirt] [PATCH] Remove ssp buffer size setting
by Ján Tomko 06 Jun '14

06 Jun '14

This option only makes sense with -fstack-protector. With -fstack-protector-all, even functions with buffers smaller than this are protected. https://bugzilla.redhat.com/show_bug.cgi?id=1105456 --- m4/virt-compile-warnings.m4 | 8 -------- 1 file changed, 8 deletions(-) diff --git a/m4/virt-compile-warnings.m4 b/m4/virt-compile-warnings.m4 index 574fbc4..ebc931d 100644 --- a/m4/virt-compile-warnings.m4 +++ b/m4/virt-compile-warnings.m4 @@ -171,14 +171,6 @@ AC_DEFUN([LIBVIRT_COMPILE_WARNINGS],[ dnl be great overhead in adding -fstack-protector-all instead dnl wantwarn="$wantwarn -fstack-protector" wantwarn="$wantwarn -fstack-protector-all" - wantwarn="$wantwarn --param=ssp-buffer-size=4" - dnl Even though it supports it, clang complains about - dnl use of --param=ssp-buffer-size=4 unless used with - dnl the -c arg. It doesn't like it when used with args - dnl that just link together .o files. Unfortunately - dnl we can't avoid that with automake, so we must turn - dnl off the following clang specific warning - wantwarn="$wantwarn -Wno-unused-command-line-argument" ;; *-*-freebsd*) dnl FreeBSD ships old gcc 4.2.1 which doesn't handle -- 1.8.3.2

4 4

[libvirt] libvirt / libxl testing emails
by George Dunlap 06 Jun '14

06 Jun '14

Ian / Ian, Daniel V. was lurking on a recent CentOS Virt SIG IRC meetings, and asked about testing the libvirt git repo against libxl. I mentioned that we already had some basic tests to do that, and he asked whether it would make sense to have the push gate e-mail the libvirt list. I have no idea how the libvirt people feel about that, so I'll let DV make his case, and also let he Ians give their opinions. -George

4 7