- Devel - libvirt List Archives

[libvirt] [PATCH 0/2] Two trivial fixes
by Peter Krempa 18 Jun '15

18 Jun '15

Both are now pushed. Peter Krempa (2): qemu: Jump to correct label in qemuDomainPinIOThread qemu: Fix double space in error message in qemuDomainGetVcpusFlags src/qemu/qemu_driver.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.4.1

1 2

[libvirt] [PATCH 00/13] vCPU pinning and related refactors - Part 1.5
by Peter Krempa 18 Jun '15

18 Jun '15

Few more fixes to the Part 1 and related stuff. This is a continuation and fix to stuff done in Part 1. Peter Krempa (13): conf: Fix virDomainObjGetDefs when getting persistent config on a live vm conf: Introduce helper to help getting correct def for getter functions qemu: Simplify qemuDomainGetInterfaceParameters by using virDomainObjGetOneDef qemu: Simplify qemuDomainGetNumaParameters by using virDomainObjGetOneDef qemu: Simplify qemuDomainGetVcpuPinInfo by using virDomainObjGetOneDef qemu: Simplify qemuDomainGetEmulatorPinInfo by using virDomainObjGetOneDef qemu: Simplify qemuDomainGetVcpusFlags by using virDomainObjGetOneDef qemu: Simplify qemuDomainSetInterfaceParameters by using virDomainObjGetDefs qemu: Refactor qemuDomainSetNumaParameters qemu: Refactor qemuDomainGetMemoryParameters qemu: Reuse virDomainObjGetDefs in qemuDomainGetMemoryParameters qemu: 'privileged' flag is not really configuration conf: Move vcpu info parsing code into a separate function src/conf/domain_conf.c | 174 ++++++++++++++++--------- src/conf/domain_conf.h | 1 + src/libvirt_private.syms | 1 + src/qemu/qemu_cgroup.c | 13 +- src/qemu/qemu_command.c | 9 +- src/qemu/qemu_conf.c | 7 +- src/qemu/qemu_conf.h | 5 +- src/qemu/qemu_domain.c | 4 +- src/qemu/qemu_driver.c | 332 ++++++++++++++--------------------------------- tests/qemuxml2argvtest.c | 4 +- 10 files changed, 241 insertions(+), 309 deletions(-) -- 2.4.1

2 20

Re: [libvirt] [Qemu-block] [Qemu-devel] [PATCH v7 00/11] Support streaming to an intermediate layer
by Eric Blake 18 Jun '15

18 Jun '15

[adding libvirt, to make sure I capture a design idea] On 06/18/2015 06:36 AM, Eric Blake wrote: > On 06/18/2015 06:07 AM, Alberto Garcia wrote: >> On Thu 18 Jun 2015 01:47:20 PM CEST, Kevin Wolf wrote: >> >>>>> I believe our conclusion from an earlier version of the series was >>>>> that we need QAPI introspection so that libvirt can detect the >>>>> presence of the feature. > > Detecting the presence of a feature allows libvirt the luxury of giving > its own error message, rather than relying on the qemu message. But > that's not to say libvirt HAS to use its own error message, and > therefore being unable to detect the feature may not be the end of the > world. > >> That said, I would prefer a way to detect the feature that does not >> involve testing commands for their error codes, but is there any? What >> does libvirt generally do in order to detect new features that don't >> depend on API changes? > > But libvirt has not yet set up node name management (I'm about to revive > Jeff's patch for auto-node-naming simultaneously with a libvirt patch > series that proves that it helps libvirt), and libvirt will need a new > API to allow users a way to request streams to an intermediate image. > So anything libvirt does to interact with the new stream-to-intermediate > will have to be new code, and I can worry about whether the qemu error > message is good enough, or whether I have to contrive some probing test > to see if it even works; but my initial thought is that merely probing > to see if auto-node-naming is in place is a good approximation filter > (if libvirt isn't managing its own node names, then the only way to use > stream-to-intermediate is via a node name automatically supplied by > qemu, especially nice if both features land in 2.4). Actually, in thinking more about it, libvirt won't need a new API; the existing virDomainBlockPull() and virDomainBlockRebase() are sufficient, if I allow libvirt to treat "vda[1]" as a destination (which is the first backing image of disk vda; pretty much similar to how qemu is adding node names rather than device names as a way to make the existing block-stream now stream to intermediate). And that is consistent with the way we have been retrofitting other existing libvirt API to refer to specific backing images. On libvirt's front, I may want to add a new flag (where the flag must be present to make it clear that stream-to-intermediate is desired, so that upper level applications can use the absence of the libvirt flag as their feature probe), but that has no bearing on what qemu has to do to turn on the feature. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

1 0

[libvirt] [PATCH] qemu: implement address for isa-serial
by James Cowgill 18 Jun '15

18 Jun '15

I needed to specify the iobase address for certain exotic mips configurations. Signed-off-by: James Cowgill <james410(a)cowgill.org.uk> --- src/qemu/qemu_command.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 61faa57..e1d53c2 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -2693,6 +2693,10 @@ qemuBuildDeviceAddressStr(virBufferPtr buf, info->addr.ccw.cssid, info->addr.ccw.ssid, info->addr.ccw.devno); + } else if (info->type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_ISA) { + virBufferAsprintf(buf, ",iobase=0x%x,irq=0x%x", + info->addr.isa.iobase, + info->addr.isa.irq); } ret = 0; @@ -10950,11 +10954,15 @@ qemuBuildSerialChrDeviceStr(char **deviceStr, break; case VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_ISA: - if (serial->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE) { + if (serial->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE && + serial->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_ISA) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", - _("no addresses are supported for isa-serial")); + _("isa-serial requires address of isa type")); goto error; } + + if (qemuBuildDeviceAddressStr(&cmd, def, &serial->info, qemuCaps) < 0) + goto error; break; case VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_PCI: -- 2.1.4

2 3

[libvirt] [PATCH 0/2] Yet again a admin API fixup series.
by Peter Krempa 18 Jun '15

18 Jun '15

Fluffy bunny ears of shame will be administered to Martin. Peter Krempa (2): rpc: Actually increase reference count on @srv in virNetDaemonAddServer daemon: Add the admin service to the admin server only if it was allocated daemon/libvirtd.c | 6 +++--- src/rpc/virnetdaemon.c | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) -- 2.4.1

2 4

[libvirt] Overhead for a default cpu cg placement scheme
by Andrey Korolyov 18 Jun '15

18 Jun '15

Hi Daniel, would it possible to adopt an optional tunable for a virCgroup mechanism which targets to a disablement of a nested (per-thread) cgroup creation? Those are bringing visible overhead for many-threaded guest workloads, almost 5% in non-congested host CPU state, primarily because the host scheduler should make a much more decisions with those cgroups than without them. We also experienced a lot of host lockups with currently exploited cgroup placement and disabled nested behavior a couple of years ago. Though the current patch is simply carves out the mentioned behavior, leaving only top-level per-machine cgroups, it can serve for an upstream after some adaptation, that`s why I`m asking about a chance of its acceptance. This message is a kind of 'request of a feature', it either can be accepted/dropped from our side or someone may give a hand and redo it from scratch. The detailed benchmarks are related to a host 3.10.y, if anyone is interested in the numbers for latest stable, I can update those. Thanks!

2 10

[libvirt] [RFC v2][remote]
by Nikolay Shirokovskiy 18 Jun '15

18 Jun '15

Hello. I'll reword the previous letter. In libvirt we have connection close callback for drivers that have persistent internal connection to notify client that this connection is closed. Vz driver has internal persistent connection so I wanted to add support of this callback to vz driver. Now clients with connections urls like 'vz:///system' are notified of connection close event. But if connection url is like 'vz+<transport>://system we have a remote driver between client and vz driver and client is not notified as remote driver doesn't handle this event. The problem is that remote driver can't just relay this event as domain one as there is no means to do it in driver interface. The quick fix is to close the connection between daemon and remote driver from daemon side is case of close event. This will trigger connection close event in remote driver and client finally will be notified. I doubt this is a good approach as it looks like we forced to take specific action of closing connection to daemon only due to lack of appropriate driver interface. So the proposition is to move connection close event registration/deregistration/notifying to driver level so remote driver could relay them just like say domain events.

2 2

[libvirt] [PATCH v2] virSysinfo: Introduce SMBIOS type 2 support
by Michal Privoznik 18 Jun '15

18 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1220527 This type of information defines attributes of a system baseboard. With one caveat: in qemu they call it family, while in the specification it's referred to as type. I'm sticking with the latter. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- diff to v1: -I've dropped the 'family' attribute. It's not implemented in qemu yet. We can add it later. docs/formatdomain.html.in | 37 ++++- docs/schemas/domaincommon.rng | 23 +++ src/conf/domain_conf.c | 63 ++++++++ src/libvirt_private.syms | 1 + src/qemu/qemu_command.c | 54 +++++++ src/util/virsysinfo.c | 170 ++++++++++++++++++++- src/util/virsysinfo.h | 16 ++ .../qemuxml2argv-smbios-multiple-type2.xml | 58 +++++++ tests/qemuxml2argvdata/qemuxml2argv-smbios.args | 2 + tests/qemuxml2argvdata/qemuxml2argv-smbios.xml | 8 + tests/qemuxml2xmltest.c | 1 + 11 files changed, 427 insertions(+), 6 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-smbios-multiple-type2.xml diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 0478cb2..977660e 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -375,6 +375,12 @@ <entry name='product'>Virt-Manager</entry> <entry name='version'>0.9.4</entry> </system> + <baseBoard> + <entry name='manufacturer'>LENOVO</entry> + <entry name='product'>20BE0061MC</entry> + <entry name='version'>0B98401 Pro</entry> + <entry name='serial'>W1KS427111E</entry> + </baseBoard> </sysinfo> ...</pre> @@ -435,11 +441,32 @@ <dt><code>family</code></dt> <dd>Identify the family a particular computer belongs to.</dd> </dl> - NB: Incorrectly supplied entries in either the <code>bios</code> - or <code>system</code> blocks will be ignored without error. - Other than <code>uuid</code> validation and <code>date</code> - format checking, all values are passed as strings to the - hypervisor driver. + </dd> + <dt><code>baseBoard</code></dt> + <dd> + This is block 2 of SMBIOS. This element can be repeated multiple + times, to describe all the base boards. However, not all + hypervisors support the repetition necessarily. The element can + have the following children: + <dl> + <dt><code>manufacturer</code></dt> + <dd>Manufacturer of BIOS</dd> + <dt><code>product</code></dt> + <dd>Product Name</dd> + <dt><code>version</code></dt> + <dd>Version of the product</dd> + <dt><code>serial</code></dt> + <dd>Serial number</dd> + <dt><code>asset</code></dt> + <dd>Asset tag</dd> + <dt><code>location</code></dt> + <dd>Location in chassis</dd> + </dl> + NB: Incorrectly supplied entries for the + <code>bios</code>, <code>system</code> or <code>baseBoard</code> + blocks will be ignored without error. Other than <code>uuid</code> + validation and <code>date</code> format checking, all values are + passed as strings to the hypervisor driver. </dd> </dl> </dd> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index e38b927..32d28cd 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -4248,6 +4248,18 @@ </oneOrMore> </element> </optional> + <zeroOrMore> + <element name="baseBoard"> + <oneOrMore> + <element name="entry"> + <attribute name="name"> + <ref name="sysinfo-baseBoard-name"/> + </attribute> + <ref name="sysinfo-value"/> + </element> + </oneOrMore> + </element> + </zeroOrMore> </interleave> </element> </define> @@ -4273,6 +4285,17 @@ </choice> </define> + <define name="sysinfo-baseBoard-name"> + <choice> + <value>manufacturer</value> + <value>product</value> + <value>version</value> + <value>serial</value> + <value>asset</value> + <value>location</value> + </choice> + </define> + <define name="sysinfo-value"> <data type="string"> <param name='pattern'>[a-zA-Z0-9/\-_\. ]+</param> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index bf7eeb2..c2174d9 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -11227,6 +11227,65 @@ virSysinfoSystemParseXML(xmlNodePtr node, return ret; } +static int +virSysinfoBaseBoardParseXML(xmlXPathContextPtr ctxt, + virSysinfoBaseBoardDefPtr *baseBoard, + size_t *nbaseBoard) +{ + int ret = -1; + virSysinfoBaseBoardDefPtr boards = NULL; + size_t i, nboards = 0; + char *board_type = NULL; + xmlNodePtr *nodes = NULL, oldnode = ctxt->node; + int n; + + if ((n = virXPathNodeSet("./baseBoard", ctxt, &nodes)) < 0) + return ret; + + if (n && VIR_ALLOC_N(boards, n) < 0) + goto cleanup; + + for (i = 0; i < n; i++) { + virSysinfoBaseBoardDefPtr def = boards + nboards; + + ctxt->node = nodes[i]; + + def->manufacturer = + virXPathString("string(entry[@name='manufacturer'])", ctxt); + def->product = + virXPathString("string(entry[@name='product'])", ctxt); + def->version = + virXPathString("string(entry[@name='version'])", ctxt); + def->serial = + virXPathString("string(entry[@name='serial'])", ctxt); + def->asset = + virXPathString("string(entry[@name='asset'])", ctxt); + def->location = + virXPathString("string(entry[@name='location'])", ctxt); + + if (!def->manufacturer && !def->product && !def->version && + !def->serial && !def->asset && !def->location) { + /* nada */ + } else { + nboards++; + } + } + + *baseBoard = boards; + *nbaseBoard = nboards; + boards = NULL; + nboards = 0; + ret = 0; + cleanup: + while (nboards--) + virSysinfoBaseBoardDefClear(&boards[nboards]); + VIR_FREE(boards); + VIR_FREE(board_type); + VIR_FREE(nodes); + ctxt->node = oldnode; + return ret; +} + static virSysinfoDefPtr virSysinfoParseXML(xmlNodePtr node, xmlXPathContextPtr ctxt, @@ -11281,6 +11340,10 @@ virSysinfoParseXML(xmlNodePtr node, ctxt->node = oldnode; } + /* Extract system base board metadata */ + if (virSysinfoBaseBoardParseXML(ctxt, &def->baseBoard, &def->nbaseBoard) < 0) + goto error; + cleanup: VIR_FREE(type); return def; diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index dc8a52d..2348f14 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -2182,6 +2182,7 @@ virVasprintfInternal; # util/virsysinfo.h +virSysinfoBaseBoardDefClear; virSysinfoBIOSDefFree; virSysinfoDefFree; virSysinfoFormat; diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index c34fe8a..03f8e66 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -6779,6 +6779,45 @@ static char *qemuBuildSmbiosSystemStr(virSysinfoSystemDefPtr def, return NULL; } +static char *qemuBuildSmbiosBaseBoardStr(virSysinfoBaseBoardDefPtr def) +{ + virBuffer buf = VIR_BUFFER_INITIALIZER; + + if (!def) + return NULL; + + virBufferAddLit(&buf, "type=2"); + + /* 2:Manufacturer */ + if (def->manufacturer) + virBufferAsprintf(&buf, ",manufacturer=%s", + def->manufacturer); + /* 2:Product Name */ + if (def->product) + virBufferAsprintf(&buf, ",product=%s", def->product); + /* 2:Version */ + if (def->version) + virBufferAsprintf(&buf, ",version=%s", def->version); + /* 2:Serial Number */ + if (def->serial) + virBufferAsprintf(&buf, ",serial=%s", def->serial); + /* 2:Asset Tag */ + if (def->asset) + virBufferAsprintf(&buf, ",asset=%s", def->asset); + /* 2:Location */ + if (def->location) + virBufferAsprintf(&buf, ",location=%s", def->location); + + if (virBufferCheckError(&buf) < 0) + goto error; + + return virBufferContentAndReset(&buf); + + error: + virBufferFreeAndReset(&buf); + return NULL; +} + static char * qemuBuildClockArgStr(virDomainClockDefPtr def) { @@ -9057,6 +9096,21 @@ qemuBuildCommandLine(virConnectPtr conn, virCommandAddArgList(cmd, "-smbios", smbioscmd, NULL); VIR_FREE(smbioscmd); } + + if (source->nbaseBoard > 1) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("qemu does not support more than " + "one entry to Type 2 in SMBIOS table")); + goto error; + } + + for (i = 0; i < source->nbaseBoard; i++) { + if (!(smbioscmd = qemuBuildSmbiosBaseBoardStr(source->baseBoard + i))) + goto error; + + virCommandAddArgList(cmd, "-smbios", smbioscmd, NULL); + VIR_FREE(smbioscmd); + } } } diff --git a/src/util/virsysinfo.c b/src/util/virsysinfo.c index 692c921..a4d31c9 100644 --- a/src/util/virsysinfo.c +++ b/src/util/virsysinfo.c @@ -91,6 +91,18 @@ void virSysinfoSystemDefFree(virSysinfoSystemDefPtr def) VIR_FREE(def); } +void virSysinfoBaseBoardDefClear(virSysinfoBaseBoardDefPtr def) +{ + if (def == NULL) + return; + + VIR_FREE(def->manufacturer); + VIR_FREE(def->product); + VIR_FREE(def->version); + VIR_FREE(def->serial); + VIR_FREE(def->asset); + VIR_FREE(def->location); +} /** * virSysinfoDefFree: @@ -109,6 +121,10 @@ void virSysinfoDefFree(virSysinfoDefPtr def) virSysinfoBIOSDefFree(def->bios); virSysinfoSystemDefFree(def->system); + for (i = 0; i < def->nbaseBoard; i++) + virSysinfoBaseBoardDefClear(def->baseBoard + i); + VIR_FREE(def->baseBoard); + for (i = 0; i < def->nprocessor; i++) { VIR_FREE(def->processor[i].processor_socket_destination); VIR_FREE(def->processor[i].processor_type); @@ -717,6 +733,84 @@ virSysinfoParseSystem(const char *base, virSysinfoSystemDefPtr *system) } static int +virSysinfoParseBaseBoard(const char *base, + virSysinfoBaseBoardDefPtr *baseBoard, + size_t *nbaseBoard) +{ + int ret = -1; + const char *cur, *eol = NULL; + virSysinfoBaseBoardDefPtr boards = NULL; + size_t nboards = 0; + char *board_type = NULL; + + while (base && (cur = strstr(base, "Base Board Information"))) { + virSysinfoBaseBoardDefPtr def; + + if (VIR_EXPAND_N(boards, nboards, 1) < 0) + goto cleanup; + + def = &boards[nboards - 1]; + + base = cur + 22; + if ((cur = strstr(base, "Manufacturer: ")) != NULL) { + cur += 14; + eol = strchr(cur, '\n'); + if (eol && VIR_STRNDUP(def->manufacturer, cur, eol - cur) < 0) + goto cleanup; + } + if ((cur = strstr(base, "Product Name: ")) != NULL) { + cur += 14; + eol = strchr(cur, '\n'); + if (eol && VIR_STRNDUP(def->product, cur, eol - cur) < 0) + goto cleanup; + } + if ((cur = strstr(base, "Version: ")) != NULL) { + cur += 9; + eol = strchr(cur, '\n'); + if (eol && VIR_STRNDUP(def->version, cur, eol - cur) < 0) + goto cleanup; + } + if ((cur = strstr(base, "Serial Number: ")) != NULL) { + cur += 15; + eol = strchr(cur, '\n'); + if (eol && VIR_STRNDUP(def->serial, cur, eol - cur) < 0) + goto cleanup; + } + if ((cur = strstr(base, "Asset Tag: ")) != NULL) { + cur += 11; + eol = strchr(cur, '\n'); + if (eol && VIR_STRNDUP(def->asset, cur, eol - cur) < 0) + goto cleanup; + } + if ((cur = strstr(base, "Location In Chassis: ")) != NULL) { + cur += 21; + eol = strchr(cur, '\n'); + if (eol && VIR_STRNDUP(def->location, cur, eol - cur) < 0) + goto cleanup; + } + + if (!def->manufacturer && !def->product && !def->version && + !def->serial && !def->asset && !def->location) + nboards--; + } + + /* This is safe, as we can be only shrinking the memory */ + ignore_value(VIR_REALLOC_N(boards, nboards)); + + *baseBoard = boards; + *nbaseBoard = nboards; + boards = NULL; + nboards = 0; + ret = 0; + cleanup: + while (nboards--) + virSysinfoBaseBoardDefClear(&boards[nboards]); + VIR_FREE(boards); + VIR_FREE(board_type); + return ret; +} + +static int virSysinfoParseProcessor(const char *base, virSysinfoDefPtr ret) { const char *cur, *tmp_base; @@ -938,7 +1032,7 @@ virSysinfoRead(void) return NULL; } - cmd = virCommandNewArgList(path, "-q", "-t", "0,1,4,17", NULL); + cmd = virCommandNewArgList(path, "-q", "-t", "0,1,2,4,17", NULL); VIR_FREE(path); virCommandSetOutputBuffer(cmd, &outbuf); if (virCommandRun(cmd, NULL) < 0) @@ -955,6 +1049,9 @@ virSysinfoRead(void) if (virSysinfoParseSystem(outbuf, &ret->system) < 0) goto error; + if (virSysinfoParseBaseBoard(outbuf, &ret->baseBoard, &ret->nbaseBoard) < 0) + goto error; + ret->nprocessor = 0; ret->processor = NULL; if (virSysinfoParseProcessor(outbuf, ret) < 0) @@ -1025,6 +1122,36 @@ virSysinfoSystemFormat(virBufferPtr buf, virSysinfoSystemDefPtr def) } static void +virSysinfoBaseBoardFormat(virBufferPtr buf, + virSysinfoBaseBoardDefPtr baseBoard, + size_t nbaseBoard) +{ + virSysinfoBaseBoardDefPtr def; + size_t i; + + for (i = 0; i < nbaseBoard; i++) { + def = baseBoard + i; + + virBufferAddLit(buf, "<baseBoard>\n"); + virBufferAdjustIndent(buf, 2); + virBufferEscapeString(buf, "<entry name='manufacturer'>%s</entry>\n", + def->manufacturer); + virBufferEscapeString(buf, "<entry name='product'>%s</entry>\n", + def->product); + virBufferEscapeString(buf, "<entry name='version'>%s</entry>\n", + def->version); + virBufferEscapeString(buf, "<entry name='serial'>%s</entry>\n", + def->serial); + virBufferEscapeString(buf, "<entry name='asset'>%s</entry>\n", + def->asset); + virBufferEscapeString(buf, "<entry name='location'>%s</entry>\n", + def->location); + virBufferAdjustIndent(buf, -2); + virBufferAddLit(buf, "</baseBoard>\n"); + } +} + +static void virSysinfoProcessorFormat(virBufferPtr buf, virSysinfoDefPtr def) { size_t i; @@ -1157,6 +1284,7 @@ virSysinfoFormat(virBufferPtr buf, virSysinfoDefPtr def) virSysinfoBIOSFormat(&childrenBuf, def->bios); virSysinfoSystemFormat(&childrenBuf, def->system); + virSysinfoBaseBoardFormat(&childrenBuf, def->baseBoard, def->nbaseBoard); virSysinfoProcessorFormat(&childrenBuf, def); virSysinfoMemoryFormat(&childrenBuf, def); @@ -1241,12 +1369,40 @@ virSysinfoSystemIsEqual(virSysinfoSystemDefPtr src, return identical; } +static bool +virSysinfoBaseBoardIsEqual(virSysinfoBaseBoardDefPtr src, + virSysinfoBaseBoardDefPtr dst) +{ + bool identical = false; + + if (!src && !dst) + return true; + + if ((src && !dst) || (!src && dst)) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("Target base board does not match source")); + goto cleanup; + } + + CHECK_FIELD(manufacturer, "base board vendor"); + CHECK_FIELD(product, "base board product"); + CHECK_FIELD(version, "base board version"); + CHECK_FIELD(serial, "base board serial"); + CHECK_FIELD(asset, "base board asset"); + CHECK_FIELD(location, "base board location"); + + identical = true; + cleanup: + return identical; +} + #undef CHECK_FIELD bool virSysinfoIsEqual(virSysinfoDefPtr src, virSysinfoDefPtr dst) { bool identical = false; + size_t i; if (!src && !dst) return true; @@ -1271,6 +1427,18 @@ bool virSysinfoIsEqual(virSysinfoDefPtr src, if (!virSysinfoSystemIsEqual(src->system, dst->system)) goto cleanup; + if (src->nbaseBoard != dst->nbaseBoard) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("Target sysinfo base board count '%zu' does not match source '%zu'"), + dst->nbaseBoard, src->nbaseBoard); + goto cleanup; + } + + for (i = 0; i < src->nbaseBoard; i++) + if (!virSysinfoBaseBoardIsEqual(src->baseBoard + i, + dst->baseBoard + i)) + goto cleanup; + identical = true; cleanup: diff --git a/src/util/virsysinfo.h b/src/util/virsysinfo.h index c8cc1e8..1e51d2c 100644 --- a/src/util/virsysinfo.h +++ b/src/util/virsysinfo.h @@ -86,6 +86,18 @@ struct _virSysinfoSystemDef { char *family; }; +typedef struct _virSysinfoBaseBoardDef virSysinfoBaseBoardDef; +typedef virSysinfoBaseBoardDef *virSysinfoBaseBoardDefPtr; +struct _virSysinfoBaseBoardDef { + char *manufacturer; + char *product; + char *version; + char *serial; + char *asset; + char *location; + /* XXX board type */ +}; + typedef struct _virSysinfoDef virSysinfoDef; typedef virSysinfoDef *virSysinfoDefPtr; struct _virSysinfoDef { @@ -94,6 +106,9 @@ struct _virSysinfoDef { virSysinfoBIOSDefPtr bios; virSysinfoSystemDefPtr system; + size_t nbaseBoard; + virSysinfoBaseBoardDefPtr baseBoard; + size_t nprocessor; virSysinfoProcessorDefPtr processor; @@ -105,6 +120,7 @@ virSysinfoDefPtr virSysinfoRead(void); void virSysinfoBIOSDefFree(virSysinfoBIOSDefPtr def); void virSysinfoSystemDefFree(virSysinfoSystemDefPtr def); +void virSysinfoBaseBoardDefClear(virSysinfoBaseBoardDefPtr def); void virSysinfoDefFree(virSysinfoDefPtr def); int virSysinfoFormat(virBufferPtr buf, virSysinfoDefPtr def) diff --git a/tests/qemuxml2argvdata/qemuxml2argv-smbios-multiple-type2.xml b/tests/qemuxml2argvdata/qemuxml2argv-smbios-multiple-type2.xml new file mode 100644 index 0000000..1f6aec1 --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-smbios-multiple-type2.xml @@ -0,0 +1,58 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219100</memory> + <currentMemory unit='KiB'>219100</currentMemory> + <vcpu placement='static'>1</vcpu> + <sysinfo type='smbios'> + <bios> + <entry name='vendor'>LENOVO</entry> + <entry name='version'>6FET82WW (3.12 )</entry> + </bios> + <system> + <entry name='manufacturer'>Fedora</entry> + <entry name='product'>Virt-Manager</entry> + <entry name='version'>0.8.2-3.fc14</entry> + <entry name='serial'>32dfcb37-5af1-552b-357c-be8c3aa38310</entry> + <entry name='uuid'>c7a5fdbd-edaf-9455-926a-d65c16db1809</entry> + <entry name='sku'>1234567890</entry> + <entry name='family'>Red Hat</entry> + </system> + <baseBoard> + <entry name='manufacturer'>Hewlett-Packard</entry> + <entry name='product'>0B4Ch</entry> + <entry name='version'>D</entry> + <entry name='serial'>CZC1065993</entry> + <entry name='asset'>CZC1065993</entry> + <entry name='location'>Upside down</entry> + </baseBoard> + <baseBoard> + <entry name='manufacturer'>Lenovo</entry> + <entry name='product'>20BE0061MC</entry> + <entry name='version'>0B98401 Pro</entry> + <entry name='serial'>W1KS427111E</entry> + <entry name='location'>Not Available</entry> + </baseBoard> + </sysinfo> + <os> + <type arch='i686' machine='pc'>hvm</type> + <boot dev='hd'/> + <smbios mode='sysinfo'/> + </os> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu</emulator> + <disk type='block' device='disk'> + <source dev='/dev/HostVG/QEMUGuest1'/> + <target dev='hda' bus='ide'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='ide' index='0'/> + <controller type='usb' index='0'/> + <controller type='pci' index='0' model='pci-root'/> + <memballoon model='virtio'/> + </devices> +</domain> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-smbios.args b/tests/qemuxml2argvdata/qemuxml2argv-smbios.args index e939aca..209cf20 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-smbios.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-smbios.args @@ -4,5 +4,7 @@ pc -m 214 -smp 1 -smbios 'type=0,vendor=LENOVO,version=6FET82WW (3.12 )' \ -smbios 'type=1,manufacturer=Fedora,product=Virt-Manager,version=0.8.2-3.fc14,\ serial=32dfcb37-5af1-552b-357c-be8c3aa38310,\ uuid=c7a5fdbd-edaf-9455-926a-d65c16db1809,sku=1234567890,family=Red Hat' \ +-smbios 'type=2,manufacturer=Hewlett-Packard,product=0B4Ch,version=D,\ +serial=CZC1065993,asset=CZC1065993,location=Upside down' \ -nographic -monitor unix:/tmp/test-monitor,server,nowait -no-acpi -boot c -usb -hda \ /dev/HostVG/QEMUGuest1 -net none -serial none -parallel none diff --git a/tests/qemuxml2argvdata/qemuxml2argv-smbios.xml b/tests/qemuxml2argvdata/qemuxml2argv-smbios.xml index a2caeea..30888ae 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-smbios.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-smbios.xml @@ -18,6 +18,14 @@ <entry name='sku'>1234567890</entry> <entry name='family'>Red Hat</entry> </system> + <baseBoard> + <entry name='manufacturer'>Hewlett-Packard</entry> + <entry name='product'>0B4Ch</entry> + <entry name='version'>D</entry> + <entry name='serial'>CZC1065993</entry> + <entry name='asset'>CZC1065993</entry> + <entry name='location'>Upside down</entry> + </baseBoard> </sysinfo> <os> <type arch='i686' machine='pc'>hvm</type> diff --git a/tests/qemuxml2xmltest.c b/tests/qemuxml2xmltest.c index 44b388c..3287ea3 100644 --- a/tests/qemuxml2xmltest.c +++ b/tests/qemuxml2xmltest.c @@ -614,6 +614,7 @@ mymain(void) DO_TEST_DIFFERENT("tap-vhost-incorrect"); DO_TEST("shmem"); DO_TEST("smbios"); + DO_TEST("smbios-multiple-type2"); DO_TEST("aarch64-aavmf-virtio-mmio"); DO_TEST("memory-hotplug"); -- 2.3.6

2 2

[libvirt] [PATCH] qemu: Report all supported machine types in capabilities
by Jiri Denemark 18 Jun '15

18 Jun '15

Some machine types are only reported as canonical names for other machine types, which make it a bit harder to find what machine types are supported by a specific QEMU binary. Ideally, one would just use /capabilities/guest/arch[@name='...']/machine/text() XPath to get a list of all supported machine types, but it doesn't work right now. For example, we report <machine canonical='pc-i440fx-2.3' maxCpus='255'>pc</machine> in guest capabilities, but the corresponding <machine maxCpus='255'>pc-i440fx-2.3</machine> is missing. This is a result of QMP probing. With "-machine ?" parsing QEMU sends us two lines: pc Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-2.3) pc-i440fx-2.3 Standard PC (i440FX + PIIX, 1996) (default) while query-machines QMP command reports both in the same entry: {"name": "pc-i440fx-2.3", "is-default": true, "cpu-max": 255, "alias": "pc"} Let's make sure we always report separate <machine/> for both the canonical name and its alias and using the canonical name as the default machine type (i.e., inserting it before its alias) in case is-default is true. https://bugzilla.redhat.com/show_bug.cgi?id=1229666 Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/qemu/qemu_capabilities.c | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index ca7a7c2..e9b3bb5 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -2223,6 +2223,44 @@ int virQEMUCapsGetMachineTypesCaps(virQEMUCapsPtr qemuCaps, mach->maxCpus = qemuCaps->machineMaxCpus[i]; } + /* Make sure all canonical machine types also have their own entry so that + * /capabilities/guest/arch[@name='...']/machine/text() XPath selects all + * supported machine types. + */ + i = 0; + while (i < *nmachines) { + size_t j; + bool found = false; + virCapsGuestMachinePtr machine = (*machines)[i]; + + if (!machine->canonical) { + i++; + continue; + } + + for (j = 0; j < *nmachines; j++) { + if (STREQ(machine->canonical, (*machines)[j]->name)) { + found = true; + break; + } + } + + if (!found) { + virCapsGuestMachinePtr mach; + if (VIR_ALLOC(mach) < 0) + goto error; + if (VIR_INSERT_ELEMENT_COPY(*machines, i, *nmachines, mach) < 0) { + VIR_FREE(mach); + goto error; + } + if (VIR_STRDUP(mach->name, machine->canonical) < 0) + goto error; + mach->maxCpus = machine->maxCpus; + i++; + } + i++; + } + return 0; error: -- 2.4.3

2 2

[libvirt] [PATCH] daemon: only unref virNetServers once
by Ján Tomko 18 Jun '15

18 Jun '15

After we add srv and srvAdm to the virNetDaemon, it's its responsibility to unref them in virNetDaemonDispose. Added by commits fa14207 and d5f4241. --- daemon/libvirtd.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c index 368e10c..9e6c489 100644 --- a/daemon/libvirtd.c +++ b/daemon/libvirtd.c @@ -1589,8 +1589,6 @@ int main(int argc, char **argv) { virObjectUnref(adminProgram); virNetDaemonClose(dmn); virObjectUnref(dmn); - virObjectUnref(srv); - virObjectUnref(srvAdm); virNetlinkShutdown(); if (statuswrite != -1) { if (ret != 0) { -- 2.3.6

2 1

[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

[libvirt] [sandbox PATCH 0/3] Disk support for libvirt-sandbox
by Eren Yagdiran 17 Jun '15

17 Jun '15

Hello, These patches provide disk support for libvirt-sandbox. Implemented '--disk' parameter will be useful when integrating Docker image support for libvirt-sandbox. Currently, we only support qcow2 file format and fallback is set to RAW type. Eren Yagdiran (3): Add an utility function for guessing filetype from file extension Add configuration object for disk support Add disk parameter to virt-sandbox bin/virt-sandbox.c | 37 +++ libvirt-sandbox/Makefile.am | 3 + .../libvirt-sandbox-builder-container.c | 36 ++- libvirt-sandbox/libvirt-sandbox-builder-machine.c | 31 ++- libvirt-sandbox/libvirt-sandbox-config-disk.c | 300 +++++++++++++++++++++ libvirt-sandbox/libvirt-sandbox-config-disk.h | 86 ++++++ libvirt-sandbox/libvirt-sandbox-config.c | 275 +++++++++++++++++++ libvirt-sandbox/libvirt-sandbox-config.h | 10 + libvirt-sandbox/libvirt-sandbox-util.c | 79 ++++++ libvirt-sandbox/libvirt-sandbox-util.h | 6 + libvirt-sandbox/libvirt-sandbox.h | 1 + libvirt-sandbox/libvirt-sandbox.sym | 8 + libvirt-sandbox/tests/test-config.c | 11 + 13 files changed, 881 insertions(+), 2 deletions(-) create mode 100644 libvirt-sandbox/libvirt-sandbox-config-disk.c create mode 100644 libvirt-sandbox/libvirt-sandbox-config-disk.h create mode 100644 libvirt-sandbox/libvirt-sandbox-util.c -- 2.1.0

3 11

[libvirt] [libvirt-glib] gconfig: Fix small leak in test-domain-create
by Christophe Fergeau 17 Jun '15

17 Jun '15

The object returned by gvir_config_domain_disk_get_driver() must be unref'ed when no longer used. --- libvirt-gconfig/tests/test-domain-create.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libvirt-gconfig/tests/test-domain-create.c b/libvirt-gconfig/tests/test-domain-create.c index eb4b945..417d3d0 100644 --- a/libvirt-gconfig/tests/test-domain-create.c +++ b/libvirt-gconfig/tests/test-domain-create.c @@ -284,6 +284,7 @@ int main(int argc, char **argv) g_assert(gvir_config_domain_disk_driver_get_copy_on_read(driver)); g_assert(gvir_config_domain_disk_get_target_bus(disk) == GVIR_CONFIG_DOMAIN_DISK_BUS_IDE); g_str_const_check(gvir_config_domain_disk_get_target_dev(disk), "hda"); + g_object_unref(driver); /* network interfaces node */ -- 2.3.5

2 2

[libvirt] [sandbox] configure: check for static libc
by Cédric Bosdonnat 17 Jun '15

17 Jun '15

Missing static libc doesn't really prevent the build to finish, but it would cause errors when running qemu sandboxes. Checking in configure will save time for new developers. --- configure.ac | 2 ++ m4/virt-static.m4 | 33 +++++++++++++++++++++++++++++++++ 2 files changed, 35 insertions(+) create mode 100644 m4/virt-static.m4 diff --git a/configure.ac b/configure.ac index 0e49a0a..ba5247a 100644 --- a/configure.ac +++ b/configure.ac @@ -87,6 +87,8 @@ LIBVIRT_SANDBOX_COVERAGE LIBVIRT_SANDBOX_RPCGEN LIBVIRT_SANDBOX_SELINUX +LIBVIRT_SANDBOX_STATIC_LIBC + GOBJECT_INTROSPECTION_CHECK([$GOBJECT_INTROSPECTION_REQUIRED]) dnl Should be in m4/virt-gettext.m4 but intltoolize is too diff --git a/m4/virt-static.m4 b/m4/virt-static.m4 new file mode 100644 index 0000000..8a40351 --- /dev/null +++ b/m4/virt-static.m4 @@ -0,0 +1,33 @@ +# LIBVIRT_SANDBOX_STATIC_LIB(NAME, CFLAGS, LDFLAGS, PROLOG, PROGRAM) +# ------------------------------------------------------------------ +# Check if the program can be linked with static libraries only. +# +AC_DEFUN([LIBVIRT_SANDBOX_STATIC_LIB], [ + AC_MSG_CHECKING([for static $1]) + + SAVED_LDFLAGS=$LDFLAGS + SAVED_CFLAGS=$CFLAGS + CFLAGS="$2" + LDFLAGS="-static $3" + AC_LINK_IFELSE( + [AC_LANG_PROGRAM([$4], + [$5])], + [], + [AC_MSG_RESULT([no])] + [AC_MSG_ERROR([static $1 is required in order to build virt-sandbox-init-qemu])] + ) + LDFLAGS=$SAVED_LDFLAGS + CFLAGS=$SAVED_CFLAGS + + AC_MSG_RESULT([yes]) +]) + +AC_DEFUN([LIBVIRT_SANDBOX_STATIC_LIBC], [ + LIBVIRT_SANDBOX_STATIC_LIB( + [LIBC], + [], + [], + [#include <stdio.h>], + [printf("bar");]) +]) + -- 2.1.4

2 1

[libvirt] [RFC] libvirt hugepage hooks
by Alex Williamson 16 Jun '15

16 Jun '15

Hi, This is very rough and early, but I wanted to get some feedback, possibly advice, and see if there's some interest in at least creating infrastructure for user contributed libvirt hooks, if not some default ones that are no-ops unless configured. The impetus for this is that I started trying to tune a dual-socket system for performance with device assignment and quickly became very frustrated that distros don't provide any built-in support for more than the very basics of hugepages. Yes, there are kernel commandline options, but those don't allow node specific configuration. Yes, there's 'virsh allocpages', but how does that get incorporated automatically into initializing libvirtd or a domain? Creating any sort of persistence for hugepages is an exercise for the user. So I think the first step in this is that the hooks scripts[1] should by default support sub-scripts in the common way, with a ".d" sub-directory holding those scripts, for example daemon.d and qemu.d. In the attached file, I've simply commandeered the default script to call the sub-scripts. For compatibility (ie. not overwriting user scripts), that should probably happen within libvirt. In any case, a single monolithic hook file is impossible to maintain on a system, let alone multiple systems, so this needs to be brought up to date. The second step is that even if we drop user contrib hooks out in /usr/share for admins to pull in as desired, perhaps we can provide some consistency for how to configure those hooks. In the example below I propose /etc/sysconfig/libvirt-hook-config.xml. You can see how currently it supports static and dynamic hugepage hooks, static occurring through the daemon hook and dynamic through the qemu hook. Ideally the dynamic hook would simply list the domain names participating in dynamic hugepages and figure out what needs to be allocated where from the domain xml. I haven't gotten that far (and frankly trying to satisfy cpu/numa vs numatune/memory|memnode vs memoryBacking/hugepages and memory size still looks very confusing to me). Do we want a common place to configure this sort of thing? Is XML the right format? On to the scripts themselves. I got some advice on #virt that I should use 'virsh allocpages' to manage hugepages. Despite the warning not to call into libvirt in the hook documentation[1], I was assured it'd be ok here. However, somehow 'virsh freepages' did manage to hang and my RHEL7.1 system doesn't support allocpages yet, so my prototype uses raw sysfs. AFAICT, any sort of hugepage manipulation is inherently broken because of the racy kernel interfaces. We really need a hugepage broker, but that's well beyond the scope of libvirt. Functionally this seems to work well for me. I don't know how practical it is to support dynamic 1G pages; I'd probably encourage static setup for that as my system only survived a couple rounds before getting too fragmented. 2M dynamic seems to work quite nicely though. TL;DR, I thought I'd post this, even in a rough state to see if there's interest, get nitpicks at my terrible scripting, and make sure I'm not just scratching my own itch. Thanks, Alex [1] https://www.libvirt.org/hooks.html

1 0

[libvirt] [[libvirt-php][PATCH v1] qemu-agent-command] fixes for installation and add another libvirt function
by Vasiliy Tolstov 16 Jun '15

16 Jun '15

* add libvirt_domain_qemu_agent_command * fix install target, because before this all stuff goes to /usr/usr dir Signed-off-by: Vasiliy Tolstov <v.tolstov(a)selfip.ru> --- configure.ac | 3 +++ src/Makefile.am | 19 ++++++++++--------- src/libvirt-php.c | 28 ++++++++++++++++++++++++++++ src/libvirt-php.h | 2 ++ 4 files changed, 43 insertions(+), 9 deletions(-) diff --git a/configure.ac b/configure.ac index 9e9fee0..0afa2e2 100644 --- a/configure.ac +++ b/configure.ac @@ -23,6 +23,9 @@ PKG_PROG_PKG_CONFIG LIBVIRT_REQUIRED=0.6.2 PKG_CHECK_MODULES(LIBVIRT, libvirt >= $LIBVIRT_REQUIRED) +PKG_CHECK_MODULES(QEMU, libvirt-qemu) +AC_SUBST([QEMU_CFLAGS]) +AC_SUBST([QEMU_LIBS]) dnl ========================================================================== dnl required minimum version of libxml2 diff --git a/src/Makefile.am b/src/Makefile.am index cab0456..f270ec2 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -6,10 +6,10 @@ WL=@WL@ SHLIB_FLAGS=@SHLIB_FLAGS@ install-exec-local: - $(MKDIR_P) $(DESTDIR)$(prefix)$(PHPEDIR) - $(MKDIR_P) $(DESTDIR)$(prefix)$(PHPCDIR) - $(INSTALL) -m 644 -D .libs/$(PACKAGE).so $(DESTDIR)$(prefix)$(PHPEDIR)/$(PACKAGE).so - $(INSTALL) -m 755 -d $(DESTDIR)$(prefix)$(PHPCDIR) + $(MKDIR_P) $(DESTDIR)$(PHPEDIR) + $(MKDIR_P) $(DESTDIR)$(PHPCDIR) + $(INSTALL) -m 644 -D .libs/$(PACKAGE).so $(DESTDIR)$(PHPEDIR)/$(PACKAGE).so + $(INSTALL) -m 755 -d $(DESTDIR)$(PHPCDIR) $(ECHO) "extension=$(PACKAGE).so" > libvirt-php.ini $(ECHO) >> libvirt-php.ini $(ECHO) "[libvirt]" >> libvirt-php.ini @@ -19,21 +19,22 @@ install-exec-local: $(ECHO) "libvirt.image_path=/var/lib/libvirt/images" >> libvirt-php.ini $(ECHO) "; Limit maximum number of libvirt connections" >> libvirt-php.ini $(ECHO) "libvirt.max_connections=5" >> libvirt-php.ini - $(INSTALL) -m 644 -D libvirt-php.ini $(DESTDIR)$(prefix)$(PHPCDIR)/$(PACKAGE).ini + $(INSTALL) -m 644 -D libvirt-php.ini $(DESTDIR)$(PHPCDIR)/$(PACKAGE).ini uninstall-local: - $(RM) -f $(DESTDIR)$(prefix)$(PHPCDIR)/$(PACKAGE).ini - $(RM) -f $(DESTDIR)$(prefix)$(PHPEDIR)/$(PACKAGE).so + $(RM) -f $(DESTDIR)$(PHPCDIR)/$(PACKAGE).ini + $(RM) -f $(DESTDIR)$(PHPEDIR)/$(PACKAGE).so AM_CFLAGS = \ $(PHPINC) $(LIBXML_CFLAGS) \ - $(LIBVIRT_CFLAGS) $(DEFINES) \ + $(LIBVIRT_CFLAGS) $(QEMU_CFLAGS) $(DEFINES) \ -I$(top_srcdir)/winsrc AM_LDFLAGS = \ $(SHLIB_LDFLAGS) \ $(LIBXML_LIBS) \ - $(LIBVIRT_LIBS) + $(LIBVIRT_LIBS) \ + $(QEMU_LIBS) lib_LTLIBRARIES = libvirt-php.la diff --git a/src/libvirt-php.c b/src/libvirt-php.c index d46fbb9..161abca 100644 --- a/src/libvirt-php.c +++ b/src/libvirt-php.c @@ -161,6 +161,7 @@ static zend_function_entry libvirt_functions[] = { PHP_FE(libvirt_domain_send_keys, NULL) PHP_FE(libvirt_domain_send_pointer_event, NULL) PHP_FE(libvirt_domain_update_device, NULL) + PHP_FE(libvirt_domain_qemu_agent_command, NULL) /* Domain snapshot functions */ PHP_FE(libvirt_domain_has_current_snapshot, NULL) PHP_FE(libvirt_domain_snapshot_create, NULL) @@ -3943,6 +3944,33 @@ PHP_FUNCTION(libvirt_domain_get_name) } /* + Function name: libvirt_domain_qemu_agent_command + Since version: 0.5.2(-1) + Description: Function is used to send qemu-ga command + Arguments: @res [resource]: libvirt domain resource, e.g. from libvirt_domain_lookup_by_*() + @timeout [int]: timeout for waiting (-2 block, -1 default, 0 no wait, >0 wait specific time + @flags [int]: ?? + Returns: String on success and FALSE on error +*/ +PHP_FUNCTION(libvirt_domain_qemu_agent_command) +{ + php_libvirt_domain *domain=NULL; + zval *zdomain; + const char *cmd; + int cmd_len; + char *ret; + long timeout = -1; + long flags = 0; + + GET_DOMAIN_FROM_ARGS("rs|l|l", &zdomain, &cmd, &cmd_len, &timeout, &flags); + + ret = virDomainQemuAgentCommand(domain->domain, cmd, timeout, flags); + if (ret == NULL) RETURN_FALSE; + + RETURN_STRING(ret,0); +} + +/* Function name: libvirt_domain_get_uuid_string Since version: 0.4.1(-1) Description: Function is used to get the domain's UUID in string format diff --git a/src/libvirt-php.h b/src/libvirt-php.h index 7c9a229..1d9c6ab 100644 --- a/src/libvirt-php.h +++ b/src/libvirt-php.h @@ -80,6 +80,7 @@ #include <libvirt/libvirt.h> #include <libvirt/virterror.h> +#include <libvirt/libvirt-qemu.h> #include <libxml/parser.h> #include <libxml/xpath.h> #include <fcntl.h> @@ -427,6 +428,7 @@ PHP_FUNCTION(libvirt_domain_send_keys); PHP_FUNCTION(libvirt_domain_send_pointer_event); PHP_FUNCTION(libvirt_domain_get_metadata); PHP_FUNCTION(libvirt_domain_set_metadata); +PHP_FUNCTION(libvirt_domain_qemu_agent_command); /* Domain snapshot functions */ PHP_FUNCTION(libvirt_domain_has_current_snapshot); PHP_FUNCTION(libvirt_domain_snapshot_create); -- 2.3.3

1 0