July 2017 - Devel - libvirt List Archives

[libvirt] [PATCH v2 0/6] nwfilter adjustments for common object
by John Ferlan 15 Aug '17

15 Aug '17

v1: https://www.redhat.com/archives/libvir-list/2017-June/msg00079.html Changes since v1 (if I can recall all of them!): Patches 1, 4, 8-13 were pushed Patches 2, 3, 5-7 are dropped This this is a rework of patches 14-17 Patch 1 (former patch14): * Requested adjustments made to ACK'd patch, but since this and the remaining ones were related I didn't yet push it. Patch 2 (new): * From review though... As it turns out, virNWFilterDefEqual doesn't require the @cmpUUIDs patch. Patch 3 (fromer patch 15): * Fixed the line as requested. Patch was ACK'd by like Patch 1 I held onto it since it was related. Patch 4 (former patch 16): * Let's call it a complete rewrite. Rather than rely solely on the refcnt of the object, I've added/implemented a 'trylock' mechanism which essentially will allow the subsequent patch to use the virObjectLockable (e.g. a non recursive lock). Of course as I got further into the code - I think I've come to the conclusion that there isn't a way for a @def to disappear between threads with a refcnt only mechanism because there's a few other serialized locks which would need to be hurdled before hand. Still as I found out while running the Avocado test 'nwfilter_update_vm_running.update_arp_rule' the recursion would occur because the AssignDef code would call the Instantiation with the lock from the def being updated and that's where all the awful magic needs to occur. Additionally, I found that one wouldn't want to attempt to lock the nwfilters list inside the virNWFilterObjListFindInstantiateFilter because AssignDef already had that lock. I debated needing a recursive lock there until I came to the conclusion that the list couldn't change because the DefineXML is protected by a driver level lock (as is the Undefine and Reload paths). Patch 5 (former patch 17): * No changes, it was ACK'd, but without 1-4 is useless Patch 6 (NEW): * Remove the need for the driver level lock for a few API's since we have self locking nwfilters list. Also left comments in the 3 places where that lock remained to hopefully cause someone great anxiety if they decided to attempt to remove the lock without first consulting a specialist. NB: Ran all of the changes through the 'nwfilter' tests found in the Avocado test suite. John Ferlan (6): nwfilter: Add @refs logic to __virNWFilterObj nwfilter: Remove unnecessary UUID comparison bypass nwfilter: Convert _virNWFilterObjList to be a virObjectLockable nwfilter: Remove recursive locking for nwfilter instantiation nwfilter: Convert virNWFilterObj to use virObjectLockable nwfilter: Remove need for nwfilterDriverLock in some API's src/conf/virnwfilterobj.c | 635 ++++++++++++++++++++++++--------- src/conf/virnwfilterobj.h | 12 +- src/libvirt_private.syms | 6 +- src/nwfilter/nwfilter_driver.c | 66 ++-- src/nwfilter/nwfilter_gentech_driver.c | 66 +++- src/util/virobject.c | 24 ++ src/util/virobject.h | 4 + src/util/virthread.c | 5 + src/util/virthread.h | 1 + 9 files changed, 586 insertions(+), 233 deletions(-) -- 2.9.4

1 8

[libvirt] [PATCH] hostdev: display leading zeros of USB vendor/product id's in error messages
by Chen Hanxiao 15 Aug '17

15 Aug '17

From: Chen Hanxiao <chenhanxiao(a)gmail.com> Many vendor id's and product id's have leading zeros. Show them in error messages. Signed-off-by: Chen Hanxiao <chenhanxiao(a)gmail.com> --- src/util/virhostdev.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/util/virhostdev.c b/src/util/virhostdev.c index 579563c..0e6b5a3 100644 --- a/src/util/virhostdev.c +++ b/src/util/virhostdev.c @@ -1390,7 +1390,7 @@ virHostdevFindUSBDevice(virDomainHostdevDefPtr hostdev, } else if (!autoAddress) { goto out; } else { - VIR_INFO("USB device %x:%x could not be found at previous" + VIR_INFO("USB device %04x:%04x could not be found at previous" " address (bus:%u device:%u)", vendor, product, bus, device); } @@ -1418,12 +1418,12 @@ virHostdevFindUSBDevice(virDomainHostdevDefPtr hostdev, } else if (rc > 1) { if (autoAddress) { virReportError(VIR_ERR_OPERATION_FAILED, - _("Multiple USB devices for %x:%x were found," + _("Multiple USB devices for %04x:%04x were found," " but none of them is at bus:%u device:%u"), vendor, product, bus, device); } else { virReportError(VIR_ERR_OPERATION_FAILED, - _("Multiple USB devices for %x:%x, " + _("Multiple USB devices for %04x:%04x, " "use <address> to specify one"), vendor, product); } @@ -1435,7 +1435,7 @@ virHostdevFindUSBDevice(virDomainHostdevDefPtr hostdev, usbsrc->autoAddress = true; if (autoAddress) { - VIR_INFO("USB device %x:%x found at bus:%u device:%u (moved" + VIR_INFO("USB device %04x:%04x found at bus:%u device:%u (moved" " from bus:%u device:%u)", vendor, product, usbsrc->bus, usbsrc->device, -- 2.7.4

2 4

[libvirt] [PATCH v3 0/3] implement migrate-getmaxdowntime command
by Scott Garfinkle 15 Aug '17

15 Aug '17

Currently, the maximum tolerable downtime for a domain being migrated is write-only. This patch implements a way to query that value nondestructively. Changes from [v2]: * Resequenced and renamed patches * Use updated qemuMonitorJSONGetMigrationParams for querying migration parameters. [v1} https://www.redhat.com/archives/libvir-list/2017-July/msg00908.html [v2} https://www.redhat.com/archives/libvir-list/2017-July/msg01010.html Scott Garfinkle (3) Add virDomainMigrateGetMaxDowntime public API qemu: Implement virDomainMigrateGetMaxDowntime virsh: Add support for virDomainMigrateGetMaxDowntime --- include/libvirt/libvirt-domain.h | 4 ++++ src/driver-hypervisor.h | 6 ++++++ src/libvirt-domain.c | 45 ++++++++++++++++++++++++++++++++++++++++ src/libvirt_public.syms | 4 ++++ src/qemu/qemu_driver.c | 51 ++++++++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_monitor.h | 3 +++ src/qemu/qemu_monitor_json.c | 4 ++++ src/remote/remote_driver.c | 1 + src/remote/remote_protocol.x | 16 +++++++++++++- src/remote_protocol-structs | 8 +++++++ tools/virsh-domain.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++ tools/virsh.pod | 18 ++++++++++++++++++ 12 files changed, 205 insertions(+), 1 deletion(-)

2 6

[libvirt] [PATCH] docs: Add "PCI topology and hotplug" guidelines
by Andrea Bolognani 08 Aug '17

08 Aug '17

For all machine types except i440fx, making a guest hotplug capable requires some sort of planning. Add some information to help users make educated choices when defining the PCI topology of guests. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- docs/formatdomain.html.in | 4 +- docs/pci-hotplug.html.in | 164 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 167 insertions(+), 1 deletion(-) create mode 100644 docs/pci-hotplug.html.in diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index bceddd2..7c4450c 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -3505,7 +3505,9 @@ appear more than once, with a group of virtual devices tied to a virtual controller. Normally, libvirt can automatically infer such controllers without requiring explicit XML markup, but sometimes - it is necessary to provide an explicit controller element. + it is necessary to provide an explicit controller element, notably + when planning the <a href="pci-hotplug.html">PCI topology</a> + for guests where device hotplug is expected. </p> <pre> diff --git a/docs/pci-hotplug.html.in b/docs/pci-hotplug.html.in new file mode 100644 index 0000000..f3d1610 --- /dev/null +++ b/docs/pci-hotplug.html.in @@ -0,0 +1,164 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> +<html xmlns="http://www.w3.org/1999/xhtml"> + <body> + <h1>PCI topology and hotplug</h1> + + <ul id="toc"></ul> + + <p> + Perhaps surprisingly, most libvirt guests support only limited PCI + device hotplug out of the box, or even none at all. + </p> + <p> + The reason for this apparent limitation is the fact that each + hotplugged PCI device might require additional PCI controllers to + be added to the guest, and libvirt has no way of knowing in advance + how many devices will be hotplugged during the guest's lifetime, + thus making it impossible to automatically provide the right amount + of PCI controllers: any arbitrary number would end up being too big + for some users, and too small for others. + </p> + <p> + Ultimately, the user is the only one who knows how much the guest + will need to grow dynamically, so the responsability of planning + a suitabile PCI topology in advance falls on them. + </p> + <p> + This document aims at providing all the information needed to + successfully plan the PCI topology of a guest. Note that the + details can vary a lot between architectures and even machine + types, hence the way it's organized. + </p> + + <h2><a name="x86_64">x86_64 architecture</a></h2> + + <h3><a name="x86_64-q35">q35 machine type</a></h3> + + <p> + This is a PCI Express native machine type. The default PCI topology + looks like + </p> + +<pre> +<controller type='pci' index='0' model='pcie-root'/> +<controller type='pci' index='1' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='1' port='0x10'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> +</controller></pre> + + <p> + and supports hotplugging a single PCI Express device, either + emulated or assigned from the host. + </p> + <p> + Slots on the <code>pcie-root</code> controller do not support + hotplug, so the device will be hotplugged into the + <code>pcie-root-port</code> controller. If you plan to hotplug + more than a single PCI Express device, you should add a suitable + number of <code>pcie-root-port</code> controllers when defining + the guest: for example, add + </p> + +<pre> +<controller type='pci' model='pcie-root-port'/> +<controller type='pci' model='pcie-root-port'/> +<controller type='pci' model='pcie-root-port'/></pre> + + <p> + if you expect to hotplug up to three PCI Express devices, + either emulated or assigned from the host. That's all the + information you need to provide: libvirt will fill in the + remaining details automatically. + </p> + <p> + If you expect to hotplug legacy PCI devices, then you will need + specialized controllers, since all those mentioned above are + intended for PCI Express devices only: add + </p> + +<pre> +<controller type='pci' model='dmi-to-pci-bridge'/> +<controller type='pci' model='pci-bridge'/></pre> + + <p> + and you'll be able to hotplug up to 31 legacy PCI devices, + either emulated or assigned from the host. + </p> + + <h3><a name="x86_64-i440fx">i440fx (pc) machine type</a></h3> + + <p> + This is a legacy PCI native machine type. The default PCI + topology looks like + </p> + +<pre> +<controller type='pci' index='0' model='pci-root'/></pre> + + <p> + where each of the 31 slots on the <code>pci-root</code> + controller is hotplug capable and can accept a legacy PCI + device, either emulated or assigned from the guest. + </p> + + <h2><a name="ppc64">ppc64 architecture</a></h2> + + <h3><a name="ppc64-pseries">pseries machine type</a></h3> + + <p> + The default PCI topology for the <code>pseries</code> machine + type looks like + </p> + +<pre> +<controller type='pci' index='0' model='pcie-root'> + <model name='spapr-pci-host-bridge'/> + <target index='0'/> +</controller></pre> + + <p> + The 31 slots on a <code>pci-root</code> controller are all + hotplug capable and, despite the name suggesting otherwise, + starting with QEMU 2.9 all of them can accept PCI Express + devices in addition to legacy PCI devices; however, + libvirt will only place emulated devices on the default + <code>pci-root</code> controller. + </p> + <p> + In order to take advantage of improved error reporting and + recovering capabilities, PCI devices assigned from the + host need to be isolated by placing each on a separate + <code>pci-root</code> controller, which has to be prepared + in advance for hotplug to work: for example, add + </p> + +<pre> +<controller type='pci' model='pci-root'/> +<controller type='pci' model='pci-root'/> +<controller type='pci' model='pci-root'/></pre> + + <p> + if you expect to hotplug up to three PCI devices assigned + from the host. + </p> + + <h2><a name="aarch64">aarch64 architecture</a></h2> + + <h3><a name="aarch64-virt">mach-virt (virt) machine type</a></h3> + + <p> + This machine type mostly behaves the same as the + <a href="#x86_64-q35">q35 machine type</a>, so you can just + refer to that section for information. + </p> + <p> + The only difference worth mentioning is that using legacy + PCI for <code>mach-virt</code> guests is extremely uncommon, + so you'll probably never need to add controllers other than + <code>pcie-root-port</code>. + </p> + + </body> +</html> -- 2.7.5

3 5

Re: [libvirt] [RFC]Add new mdev interface for QoS
by Alex Williamson 08 Aug '17

08 Aug '17

[cc +libvir-list] On Wed, 26 Jul 2017 21:16:59 +0800 "Gao, Ping A" <ping.a.gao(a)intel.com> wrote: > The vfio-mdev provide the capability to let different guest share the > same physical device through mediate sharing, as result it bring a > requirement about how to control the device sharing, we need a QoS > related interface for mdev to management virtual device resource. > > E.g. In practical use, vGPUs assigned to different quests almost has > different performance requirements, some guests may need higher priority > for real time usage, some other may need more portion of the GPU > resource to get higher 3D performance, corresponding we can define some > interfaces like weight/cap for overall budget control, priority for > single submission control. > > So I suggest to add some common attributes which are vendor agnostic in > mdev core sysfs for QoS purpose. I think what you're asking for is just some standardization of a QoS attribute_group which a vendor can optionally include within the existing mdev_parent_ops.mdev_attr_groups. The mdev core will transparently enable this, but it really only provides the standard, all of the support code is left for the vendor. I'm fine with that, but of course the trouble with and sort of standardization is arriving at an agreed upon standard. Are there QoS knobs that are generic across any mdev device type? Are there others that are more specific to vGPU? Are there existing examples of this that we can steal their specification? Also, mdev devices are not necessarily the exclusive users of the hardware, we can have a native user such as a local X client. They're not an mdev user, so we can't support them via the mdev_attr_group. Does there need to be a per mdev parent QoS attribute_group standard for somehow defining the QoS of all the child mdev devices, or perhaps representing the remaining host QoS attributes? Ultimately libvirt and upper level management tools would be the consumer of these control knobs, so let's immediately get libvirt involved in the discussion. Thanks, Alex

5 16

[libvirt] [PATCH] hyperv: Reduce usage of libxml API functions
by Sri Ramanujam 07 Aug '17

07 Aug '17

Slight refactor of the WMI serialization code to minimize mixing openwsman and libxml2 APIs. The only usage of libxml2 APIs now is in creating CDATA blocks, because the openwsman API does not provide that functionality. --- src/hyperv/hyperv_wmi.c | 65 ++++++++++++------------------------------------- 1 file changed, 16 insertions(+), 49 deletions(-) diff --git a/src/hyperv/hyperv_wmi.c b/src/hyperv/hyperv_wmi.c index 57125ae..99efa1c 100644 --- a/src/hyperv/hyperv_wmi.c +++ b/src/hyperv/hyperv_wmi.c @@ -489,17 +489,14 @@ hypervSerializeSimpleParam(hypervParamPtr p, const char *resourceUri, static int hypervSerializeEprParam(hypervParamPtr p, hypervPrivate *priv, - const char *resourceUri, WsXmlDocH doc, WsXmlNodeH *methodNode) + const char *resourceUri, WsXmlNodeH *methodNode) { int result = -1; WsXmlNodeH xmlNodeParam = NULL, xmlNodeTemp = NULL, xmlNodeAddr = NULL, xmlNodeRef = NULL; - xmlNodePtr xmlNodeAddrPtr = NULL, - xmlNodeRefPtr = NULL; WsXmlDocH xmlDocResponse = NULL; - xmlDocPtr docPtr = (xmlDocPtr) doc->parserDoc; WsXmlNsH ns = NULL; client_opt_t *options = NULL; filter_t *filter = NULL; @@ -573,11 +570,6 @@ hypervSerializeEprParam(hypervParamPtr p, hypervPrivate *priv, goto cleanup; } - if (!(xmlNodeAddrPtr = xmlDocCopyNode((xmlNodePtr) xmlNodeAddr, docPtr, 1))) { - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Could not copy EPR address")); - goto cleanup; - } - if (!(xmlNodeRef = ws_xml_get_child(xmlNodeTemp, 0, XML_NS_ADDRESSING, WSA_REFERENCE_PARAMETERS))) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", @@ -585,17 +577,11 @@ hypervSerializeEprParam(hypervParamPtr p, hypervPrivate *priv, goto cleanup; } - if (!(xmlNodeRefPtr = xmlDocCopyNode((xmlNodePtr) xmlNodeRef, docPtr, 1))) { - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("Could not copy EPR item reference parameters")); - goto cleanup; - } - /* now build a new xml doc with the EPR node children */ if (!(xmlNodeParam = ws_xml_add_child(*methodNode, resourceUri, p->epr.name, NULL))) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("Could not add child node to xmlNodeParam")); + _("Could not add child node to methodNode")); goto cleanup; } @@ -613,23 +599,8 @@ hypervSerializeEprParam(hypervParamPtr p, hypervPrivate *priv, goto cleanup; } - if (xmlAddChild((xmlNodePtr) *methodNode, (xmlNodePtr) xmlNodeParam) == NULL) { - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("Could not add child to xml parent node")); - goto cleanup; - } - - if (xmlAddChild((xmlNodePtr) xmlNodeParam, xmlNodeAddrPtr) == NULL) { - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("Could not add child to xml parent node")); - goto cleanup; - } - - if (xmlAddChild((xmlNodePtr) xmlNodeParam, xmlNodeRefPtr) == NULL) { - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("Could not add child to xml parent node")); - goto cleanup; - } + ws_xml_duplicate_tree(xmlNodeParam, xmlNodeAddr); + ws_xml_duplicate_tree(xmlNodeParam, xmlNodeRef); /* we did it! */ result = 0; @@ -656,8 +627,7 @@ hypervSerializeEmbeddedParam(hypervParamPtr p, const char *resourceUri, xmlNodeArray = NULL; WsXmlDocH xmlDocTemp = NULL, xmlDocCdata = NULL; - xmlBufferPtr xmlBufferNode = NULL; - const xmlChar *xmlCharCdataContent = NULL; + char *xmlCharCdataContent = NULL; xmlNodePtr xmlNodeCdata = NULL; hypervWmiClassInfoPtr classInfo = p->embedded.info; virHashKeyValuePairPtr items = NULL; @@ -761,25 +731,22 @@ hypervSerializeEmbeddedParam(hypervParamPtr p, const char *resourceUri, } /* create CDATA node */ - xmlBufferNode = xmlBufferCreate(); - if (xmlNodeDump(xmlBufferNode, (xmlDocPtr) xmlDocTemp->parserDoc, - (xmlNodePtr) xmlNodeInstance, 0, 0) < 0) { - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("Could not get root of temp XML doc")); - goto cleanup; - } + ws_xml_dump_memory_node_tree(xmlNodeInstance, &xmlCharCdataContent, &len); - len = xmlBufferLength(xmlBufferNode); - xmlCharCdataContent = xmlBufferContent(xmlBufferNode); if (!(xmlNodeCdata = xmlNewCDataBlock((xmlDocPtr) xmlDocCdata, - xmlCharCdataContent, len))) { + (xmlChar *)xmlCharCdataContent, len))) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Could not create CDATA element")); goto cleanup; } - /* Add CDATA node to the doc root */ - if (!(xmlAddChild((xmlNodePtr) xmlNodeParam, xmlNodeCdata))) { + /* + * Add CDATA node to the doc root + * + * FIXME: there is no openwsman wrapper for xmlNewCDataBlock, so instead + * silence clang by casting to a void pointer first + */ + if (!(xmlAddChild((xmlNodePtr)(void *)xmlNodeParam, xmlNodeCdata))) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Could not add CDATA to doc root")); goto cleanup; @@ -792,7 +759,7 @@ hypervSerializeEmbeddedParam(hypervParamPtr p, const char *resourceUri, VIR_FREE(items); ws_xml_destroy_doc(xmlDocCdata); ws_xml_destroy_doc(xmlDocTemp); - xmlBufferFree(xmlBufferNode); + ws_xml_free_memory(xmlCharCdataContent); return result; } @@ -854,7 +821,7 @@ hypervInvokeMethod(hypervPrivate *priv, hypervInvokeParamsListPtr params, break; case HYPERV_EPR_PARAM: if (hypervSerializeEprParam(p, priv, params->resourceUri, - paramsDocRoot, &methodNode) < 0) + &methodNode) < 0) goto cleanup; break; case HYPERV_EMBEDDED_PARAM: -- 2.9.4

2 1

[libvirt] [PATCH] hyperv: Correct number of milliseconds in five minutes
by Sri Ramanujam 07 Aug '17

07 Aug '17

--- src/hyperv/hyperv_wmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/hyperv/hyperv_wmi.c b/src/hyperv/hyperv_wmi.c index 57125ae..33ad964 100644 --- a/src/hyperv/hyperv_wmi.c +++ b/src/hyperv/hyperv_wmi.c @@ -42,7 +42,7 @@ #define VIR_FROM_THIS VIR_FROM_HYPERV -#define HYPERV_JOB_TIMEOUT_MS 5000 +#define HYPERV_JOB_TIMEOUT_MS 300000 VIR_LOG_INIT("hyperv.hyperv_wmi"); -- 2.9.4

2 1

[libvirt] [PATCH] docs: bhyve: document autoport support
by Roman Bogorodskiy 06 Aug '17

06 Aug '17

- Update the driver page with the information about using autport for VNC ports - Add a news entry --- docs/drvbhyve.html.in | 8 ++++++++ docs/news.xml | 10 ++++++++++ 2 files changed, 18 insertions(+) It's a freeze now, but I guess it won't hurt if I push the actual feature ACKed before the freeze [1] along with this docs change. If not, it's not a big deal to let it wait for the next release though. PS I've been semi-afk for last couple of weeks, hence the delay, sorry about that. 1: https://www.redhat.com/archives/libvir-list/2017-July/msg00704.html diff --git a/docs/drvbhyve.html.in b/docs/drvbhyve.html.in index f083db91c..0cc9f0aa0 100644 --- a/docs/drvbhyve.html.in +++ b/docs/drvbhyve.html.in @@ -381,6 +381,14 @@ will be used. Please refer to the manual page and the <a href="https://wiki.freebsd.org/bhyve">bhyve wiki</a> for more details on using the <code>vgaconf</code> option.</p> +<p><span class="since">Since 3.6.0</span>, it's possible to use <code>autoport</code> +to let libvirt allocate VNC port automatically (instead of explicitly specifying +it with the <code>port</code> attribute):</p> + +<pre> + <graphics type='vnc' autoport='yes'> +</pre> + <h3><a name="clockconfig">Clock configuration</a></h3> <p>Originally bhyve supported only localtime for RTC. Support for UTC time was introduced in diff --git a/docs/news.xml b/docs/news.xml index ea21cbc3e..e84dea9ad 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -61,6 +61,16 @@ on separate PHBs (PCI Host Bridges). </description> </change> + <change> + <summary> + bhyve: Support autoport for VNC ports + </summary> + <description> + It's no longer necessary to explicitly specify VNC port for the bhyve + guests. With the autoport feature it will be allocated automatically. + Please refer to the bhyve driver documentation for examples. + </description> + </change> </section> <section title="Improvements"> <change> -- 2.13.1

3 5

[libvirt] [PATCH v2] bhyve: Add support for VNC autoport
by Roman Bogorodskiy 06 Aug '17

06 Aug '17

From: Alexander Nusov <alexander.nusov(a)nfvexpress.com> This patch adds support for automatic VNC port assignment for bhyve guests. --- Changes from v1: * Call virPortAllocatorRelease() in virBhyveProcessStop() to release VNC port; that's done unconditionally of using autoport * Call virPortAllocatorSetUsed(.., true) in virBhyveProcessReconnect() to reserve already used VNC ports after daemon restart * Call virPortAllocatorSetUsed(.., true) in bhyveBuildGraphicsArgStr() for domains that don't use autoport so allocator didn't try to use ports allocated by these domains * In dryRun mode (i.e. for domxml-to-native) don't allocate any ports * Add a couple of unit tests Note 1: while adding tests I noticed that port allocator will actually skip already bound ports, so I'm wondering if it makes any sense to use virPortAllocatorSetUsed(.., true)? Right now I cannot come up with any case to trigger this except probably some races when spawning guests simultaneously, but that's hard to reproduce. Note 2: there are still some cases where resources allocated during command preparation are not properly cleaned up; that's not only VNC ports, but also TAP devices. I plan to add proper cleanup routines separately. src/bhyve/bhyve_command.c | 25 +++++++++++-- src/bhyve/bhyve_driver.c | 5 +++ src/bhyve/bhyve_process.c | 20 +++++++++++ src/bhyve/bhyve_utils.h | 3 ++ .../bhyvexml2argv-vnc-autoport.args | 12 +++++++ .../bhyvexml2argv-vnc-autoport.ldargs | 1 + .../bhyvexml2argv-vnc-autoport.xml | 26 ++++++++++++++ tests/bhyvexml2argvtest.c | 7 ++++ .../bhyvexml2xmlout-vnc-autoport.xml | 41 ++++++++++++++++++++++ tests/bhyvexml2xmltest.c | 1 + 10 files changed, 138 insertions(+), 3 deletions(-) create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-vnc-autoport.args create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-vnc-autoport.ldargs create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-vnc-autoport.xml create mode 100644 tests/bhyvexml2xmloutdata/bhyvexml2xmlout-vnc-autoport.xml diff --git a/src/bhyve/bhyve_command.c b/src/bhyve/bhyve_command.c index eae5cb3ca..e62b5df66 100644 --- a/src/bhyve/bhyve_command.c +++ b/src/bhyve/bhyve_command.c @@ -330,15 +330,19 @@ bhyveBuildLPCArgStr(const virDomainDef *def ATTRIBUTE_UNUSED, } static int -bhyveBuildGraphicsArgStr(const virDomainDef *def ATTRIBUTE_UNUSED, +bhyveBuildGraphicsArgStr(const virDomainDef *def, virDomainGraphicsDefPtr graphics, virDomainVideoDefPtr video, virConnectPtr conn, - virCommandPtr cmd) + virCommandPtr cmd, + bool dryRun) { virBuffer opt = VIR_BUFFER_INITIALIZER; virDomainGraphicsListenDefPtr glisten = NULL; bool escapeAddr; + unsigned short port; + + bhyveConnPtr driver = conn->privateData; if (!(bhyveDriverGetCaps(conn) & BHYVE_CAP_LPC_BOOTROM) || def->os.bootloader || @@ -401,6 +405,20 @@ bhyveBuildGraphicsArgStr(const virDomainDef *def ATTRIBUTE_UNUSED, virBufferAdd(&opt, glisten->address, -1); } + if (!dryRun) { + if (graphics->data.vnc.autoport) { + if (virPortAllocatorAcquire(driver->remotePorts, &port) < 0) + return -1; + graphics->data.vnc.port = port; + } else { + if (virPortAllocatorSetUsed(driver->remotePorts, + graphics->data.vnc.port, + true) < 0) + VIR_WARN("Failed to mark VNC port '%d' as used by '%s'", + graphics->data.vnc.port, def->name); + } + } + virBufferAsprintf(&opt, ":%d", graphics->data.vnc.port); break; default: @@ -553,7 +571,8 @@ virBhyveProcessBuildBhyveCmd(virConnectPtr conn, if (def->ngraphics && def->nvideos) { if (def->ngraphics == 1 && def->nvideos == 1) { - if (bhyveBuildGraphicsArgStr(def, def->graphics[0], def->videos[0], conn, cmd) < 0) + if (bhyveBuildGraphicsArgStr(def, def->graphics[0], def->videos[0], + conn, cmd, dryRun) < 0) goto error; add_lpc = true; } else { diff --git a/src/bhyve/bhyve_driver.c b/src/bhyve/bhyve_driver.c index ed2221a35..bffeea7d9 100644 --- a/src/bhyve/bhyve_driver.c +++ b/src/bhyve/bhyve_driver.c @@ -52,6 +52,7 @@ #include "viraccessapicheck.h" #include "virhostcpu.h" #include "virhostmem.h" +#include "virportallocator.h" #include "conf/domain_capabilities.h" #include "bhyve_conf.h" @@ -1219,6 +1220,7 @@ bhyveStateCleanup(void) virObjectUnref(bhyve_driver->closeCallbacks); virObjectUnref(bhyve_driver->domainEventState); virObjectUnref(bhyve_driver->config); + virObjectUnref(bhyve_driver->remotePorts); virMutexDestroy(&bhyve_driver->lock); VIR_FREE(bhyve_driver); @@ -1265,6 +1267,9 @@ bhyveStateInitialize(bool privileged, if (!(bhyve_driver->domainEventState = virObjectEventStateNew())) goto cleanup; + if (!(bhyve_driver->remotePorts = virPortAllocatorNew(_("display"), 5900, 65535, 0))) + goto cleanup; + bhyve_driver->hostsysinfo = virSysinfoRead(); if (!(bhyve_driver->config = virBhyveDriverConfigNew())) diff --git a/src/bhyve/bhyve_process.c b/src/bhyve/bhyve_process.c index a97e300ff..7211156ca 100644 --- a/src/bhyve/bhyve_process.c +++ b/src/bhyve/bhyve_process.c @@ -293,6 +293,16 @@ virBhyveProcessStop(bhyveConnPtr driver, /* Cleanup network interfaces */ bhyveNetCleanup(vm); + /* VNC autoport cleanup */ + if ((vm->def->ngraphics == 1) && + vm->def->graphics[0]->type == VIR_DOMAIN_GRAPHICS_TYPE_VNC) { + if (virPortAllocatorRelease(driver->remotePorts, + vm->def->graphics[0]->data.vnc.port) < 0) { + VIR_WARN("Failed to release VNC port for '%s'", + vm->def->name); + } + } + ret = 0; virCloseCallbacksUnset(driver->closeCallbacks, vm, @@ -412,6 +422,16 @@ virBhyveProcessReconnect(virDomainObjPtr vm, if (STREQ(expected_proctitle, proc_argv[0])) { ret = 0; priv->mon = bhyveMonitorOpen(vm, data->driver); + if (vm->def->ngraphics == 1 && + vm->def->graphics[0]->type == VIR_DOMAIN_GRAPHICS_TYPE_VNC) { + int vnc_port = vm->def->graphics[0]->data.vnc.port; + if (virPortAllocatorSetUsed(data->driver->remotePorts, + vnc_port, + true) < 0) { + VIR_WARN("Failed to mark VNC port '%d' as used by '%s'", + vnc_port, vm->def->name); + } + } } } diff --git a/src/bhyve/bhyve_utils.h b/src/bhyve/bhyve_utils.h index db50e012a..8ad2698d4 100644 --- a/src/bhyve/bhyve_utils.h +++ b/src/bhyve/bhyve_utils.h @@ -28,6 +28,7 @@ # include "virdomainobjlist.h" # include "virthread.h" # include "virclosecallbacks.h" +# include "virportallocator.h" # define BHYVE_AUTOSTART_DIR SYSCONFDIR "/libvirt/bhyve/autostart" # define BHYVE_CONFIG_DIR SYSCONFDIR "/libvirt/bhyve" @@ -58,6 +59,8 @@ struct _bhyveConn { virCloseCallbacksPtr closeCallbacks; + virPortAllocatorPtr remotePorts; + unsigned bhyvecaps; unsigned grubcaps; }; diff --git a/tests/bhyvexml2argvdata/bhyvexml2argv-vnc-autoport.args b/tests/bhyvexml2argvdata/bhyvexml2argv-vnc-autoport.args new file mode 100644 index 000000000..039526ff3 --- /dev/null +++ b/tests/bhyvexml2argvdata/bhyvexml2argv-vnc-autoport.args @@ -0,0 +1,12 @@ +/usr/sbin/bhyve \ +-c 1 \ +-m 214 \ +-u \ +-H \ +-P \ +-s 0:0,hostbridge \ +-l bootrom,/path/to/test.fd \ +-s 2:0,ahci,hd:/tmp/freebsd.img \ +-s 3:0,virtio-net,faketapdev,mac=52:54:00:00:00:00 \ +-s 4:0,fbuf,tcp=127.0.0.1:5900 \ +-s 1,lpc bhyve diff --git a/tests/bhyvexml2argvdata/bhyvexml2argv-vnc-autoport.ldargs b/tests/bhyvexml2argvdata/bhyvexml2argv-vnc-autoport.ldargs new file mode 100644 index 000000000..421376db9 --- /dev/null +++ b/tests/bhyvexml2argvdata/bhyvexml2argv-vnc-autoport.ldargs @@ -0,0 +1 @@ +dummy diff --git a/tests/bhyvexml2argvdata/bhyvexml2argv-vnc-autoport.xml b/tests/bhyvexml2argvdata/bhyvexml2argv-vnc-autoport.xml new file mode 100644 index 000000000..afb73f040 --- /dev/null +++ b/tests/bhyvexml2argvdata/bhyvexml2argv-vnc-autoport.xml @@ -0,0 +1,26 @@ +<domain type='bhyve'> + <name>bhyve</name> + <uuid>df3be7e7-a104-11e3-aeb0-50e5492bd3dc</uuid> + <memory>219136</memory> + <vcpu>1</vcpu> + <os> + <type>hvm</type> + <loader readonly="yes" type="pflash">/path/to/test.fd</loader> + </os> + <devices> + <disk type='file'> + <driver name='file' type='raw'/> + <source file='/tmp/freebsd.img'/> + <target dev='hda' bus='sata'/> + <address type='drive' controller='0' bus='0' target='2' unit='0'/> + </disk> + <interface type='bridge'> + <model type='virtio'/> + <source bridge="virbr0"/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <graphics type='vnc' port='-1' autoport='yes'> + <listen type='address' address='127.0.0.1'/> + </graphics> + </devices> +</domain> diff --git a/tests/bhyvexml2argvtest.c b/tests/bhyvexml2argvtest.c index c8f8c685a..95fada0bd 100644 --- a/tests/bhyvexml2argvtest.c +++ b/tests/bhyvexml2argvtest.c @@ -145,6 +145,11 @@ mymain(void) if ((driver.xmlopt = virBhyveDriverCreateXMLConf(&driver)) == NULL) return EXIT_FAILURE; + if (!(driver.remotePorts = virPortAllocatorNew("display", 5900, 65535, + VIR_PORT_ALLOCATOR_SKIP_BIND_CHECK))) + return EXIT_FAILURE; + + # define DO_TEST_FULL(name, flags) \ do { \ static struct testInfo info = { \ @@ -193,6 +198,7 @@ mymain(void) DO_TEST("net-e1000"); DO_TEST("uefi"); DO_TEST("vnc"); + DO_TEST("vnc-autoport"); /* Address allocation tests */ DO_TEST("addr-single-sata-disk"); @@ -231,6 +237,7 @@ mymain(void) virObjectUnref(driver.caps); virObjectUnref(driver.xmlopt); + virObjectUnref(driver.remotePorts); return ret == 0 ? EXIT_SUCCESS : EXIT_FAILURE; } diff --git a/tests/bhyvexml2xmloutdata/bhyvexml2xmlout-vnc-autoport.xml b/tests/bhyvexml2xmloutdata/bhyvexml2xmlout-vnc-autoport.xml new file mode 100644 index 000000000..d6cfe76b7 --- /dev/null +++ b/tests/bhyvexml2xmloutdata/bhyvexml2xmlout-vnc-autoport.xml @@ -0,0 +1,41 @@ +<domain type='bhyve'> + <name>bhyve</name> + <uuid>df3be7e7-a104-11e3-aeb0-50e5492bd3dc</uuid> + <memory unit='KiB'>219136</memory> + <currentMemory unit='KiB'>219136</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='x86_64'>hvm</type> + <loader readonly='yes' type='pflash'>/path/to/test.fd</loader> + <boot dev='hd'/> + </os> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <disk type='file' device='disk'> + <driver name='file' type='raw'/> + <source file='/tmp/freebsd.img'/> + <target dev='hda' bus='sata'/> + <address type='drive' controller='0' bus='0' target='2' unit='0'/> + </disk> + <controller type='pci' index='0' model='pci-root'/> + <controller type='sata' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </controller> + <interface type='bridge'> + <mac address='52:54:00:00:00:00'/> + <source bridge='virbr0'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1'> + <listen type='address' address='127.0.0.1'/> + </graphics> + <video> + <model type='gop' heads='1' primary='yes'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </video> + </devices> +</domain> diff --git a/tests/bhyvexml2xmltest.c b/tests/bhyvexml2xmltest.c index b3759919e..c16eb2b2c 100644 --- a/tests/bhyvexml2xmltest.c +++ b/tests/bhyvexml2xmltest.c @@ -105,6 +105,7 @@ mymain(void) DO_TEST_DIFFERENT("serial-grub"); DO_TEST_DIFFERENT("serial-grub-nocons"); DO_TEST_DIFFERENT("vnc"); + DO_TEST_DIFFERENT("vnc-autoport"); /* Address allocation tests */ DO_TEST_DIFFERENT("addr-single-sata-disk"); -- 2.13.1

3 4

[libvirt] [PATCH v2 0/4] Add setting CPU features (CPUID) with libxenlight driver.
by Marek Marczykowski-Górecki 04 Aug '17

04 Aug '17

Tests (patches 3 and 4) depends on libxl_domain_config test suite: https://www.redhat.com/archives/libvir-list/2017-February/msg01477.html But first two patches can be applied independently. Marek Marczykowski-Górecki (4): cpu: define sub-leaf 0 for leaf 7 in cpu_map.xml libxl: add support for CPUID features policy tests: switch libxlxml2domconfig test to use testXLInintCaps tests: check CPU features handling in libxl driver src/cpu/cpu_map.xml | 58 ++++++------- src/libxl/libxl_conf.c | 77 ++++++++++++++++- src/libxl/libxl_conf.h | 1 +- tests/libxlxml2domconfigdata/basic-pv.xml | 2 +- tests/libxlxml2domconfigdata/fullvirt-cpuid.json | 64 ++++++++++++++- tests/libxlxml2domconfigdata/fullvirt-cpuid.xml | 37 ++++++++- tests/libxlxml2domconfigtest.c | 3 +- 7 files changed, 207 insertions(+), 35 deletions(-) create mode 100644 tests/libxlxml2domconfigdata/fullvirt-cpuid.json create mode 100644 tests/libxlxml2domconfigdata/fullvirt-cpuid.xml base-commit: fbcc08b245bb7d5502633d9cb4048281cc9d8532 -- git-series 0.9.1

3 12