November 2017 - Devel - libvirt List Archives

[libvirt] [PATCH] qemu: add support for setting OEM strings SMBIOS data fields
by Daniel P. Berrange 23 Nov '17

23 Nov '17

The OEM strings table in SMBIOS allows the vendor to pass arbitrary strings into the guest OS. This can be used as a way to pass data to an application like cloud-init, or potentially as an alternative to the kernel command line for OS installers where you can't modify the install ISO image to change the kernel args. As an example, consider if cloud-init and anaconda supported OEM strings you could use something like <oemStrings> <entry>cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/</entry> <entry>anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x8…</entry> </oemStrings> use of a application specific prefix as illustrated above is recommended so that an app can reliably identify which of the many OEM strings are targetted at it. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- NB, the QEMU side of this patch is queued but won't merge until 2.12 opens up for dev work, so this libvirt patch will need to wait a little docs/formatdomain.html.in | 13 ++++++ docs/schemas/domaincommon.rng | 9 ++++ src/conf/domain_conf.c | 53 ++++++++++++++++++++++ src/qemu/qemu_command.c | 28 ++++++++++++ src/util/virsysinfo.c | 33 ++++++++++++++ src/util/virsysinfo.h | 10 ++++ tests/qemuxml2argvdata/qemuxml2argv-smbios.args | 2 + tests/qemuxml2argvdata/qemuxml2argv-smbios.xml | 5 ++ tests/qemuxml2xmloutdata/qemuxml2xmlout-smbios.xml | 5 ++ 9 files changed, 158 insertions(+) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 8dbea6af71..bd7c542173 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -411,6 +411,10 @@ <entry name='version'>0B98401 Pro</entry> <entry name='serial'>W1KS427111E</entry> </baseBoard> + <oemStrings> + <entry>myappname:some arbitrary data</entry> + <entry>otherappname:more arbitrary data</entry> + </oemStrings> </sysinfo> ...</pre> @@ -498,6 +502,15 @@ validation and <code>date</code> format checking, all values are passed as strings to the hypervisor driver. </dd> + <dt><code>oemStrings</code></dt> + <dd> + This is block 11 of SMBIOS. This element should appear once and + can have multiple <code>entry</code> child elements, each providing + arbitrary string data. There are no restrictions on what data can + be provided in the entries, however, if the data is intended to be + consumed by an application in the guest, it is recommended to use + the application name as a prefix in the string. + </dd> </dl> </dd> </dl> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index 82fdfd5f73..98de7d2cb1 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -4834,6 +4834,15 @@ </oneOrMore> </element> </zeroOrMore> + <optional> + <element name="oemStrings"> + <oneOrMore> + <element name="entry"> + <ref name="sysinfo-value"/> + </element> + </oneOrMore> + </element> + </optional> </interleave> </element> </define> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 0e4f76f066..5d81fbb555 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -14315,6 +14315,48 @@ virSysinfoBaseBoardParseXML(xmlXPathContextPtr ctxt, return ret; } +static int +virSysinfoOEMStringsParseXML(xmlNodePtr node, + xmlXPathContextPtr ctxt, + virSysinfoOEMStringsDefPtr *oem) +{ + int ret = -1; + virSysinfoOEMStringsDefPtr def; + xmlNodePtr *strings = NULL; + int nstrings; + size_t i; + + if (!virXMLNodeNameEqual(node, "oemStrings")) { + virReportError(VIR_ERR_XML_ERROR, "%s", + _("XML does not contain expected 'system' element")); + return ret; + } + + nstrings = virXPathNodeSet("./entry", ctxt, &strings); + if (nstrings < 0) + return -1; + if (nstrings == 0) + return 0; + + if (VIR_ALLOC(def) < 0) + goto cleanup; + + if (VIR_ALLOC_N(def->values, nstrings) < 0) + goto cleanup; + + def->nvalues = nstrings; + for (i = 0; i < nstrings; i++) + def->values[i] = virXMLNodeContentString(strings[i]); + + *oem = def; + def = NULL; + ret = 0; + cleanup: + VIR_FREE(strings); + virSysinfoOEMStringsDefFree(def); + return ret; +} + static virSysinfoDefPtr virSysinfoParseXML(xmlNodePtr node, xmlXPathContextPtr ctxt, @@ -14373,6 +14415,17 @@ virSysinfoParseXML(xmlNodePtr node, if (virSysinfoBaseBoardParseXML(ctxt, &def->baseBoard, &def->nbaseBoard) < 0) goto error; + /* Extract system related metadata */ + if ((tmpnode = virXPathNode("./oemStrings[1]", ctxt)) != NULL) { + oldnode = ctxt->node; + ctxt->node = tmpnode; + if (virSysinfoOEMStringsParseXML(tmpnode, ctxt, &def->oemStrings) < 0) { + ctxt->node = oldnode; + goto error; + } + ctxt->node = oldnode; + } + cleanup: VIR_FREE(type); return def; diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 56729e4981..01fb8dff6e 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -6063,6 +6063,26 @@ qemuBuildSmbiosBaseBoardStr(virSysinfoBaseBoardDefPtr def) } +static char * +qemuBuildSmbiosOEMStringsStr(virSysinfoOEMStringsDefPtr def) +{ + virBuffer buf = VIR_BUFFER_INITIALIZER; + size_t i; + + if (!def) + return NULL; + + virBufferAddLit(&buf, "type=11"); + + for (i = 0; i < def->nvalues; i++) { + virBufferAddLit(&buf, ",value="); + virQEMUBuildBufferEscapeComma(&buf, def->values[i]); + } + + return virBufferContentAndReset(&buf); +} + + static int qemuBuildSmbiosCommandLine(virCommandPtr cmd, virQEMUDriverPtr driver, @@ -6133,6 +6153,14 @@ qemuBuildSmbiosCommandLine(virCommandPtr cmd, virCommandAddArgList(cmd, "-smbios", smbioscmd, NULL); VIR_FREE(smbioscmd); } + + if (source->oemStrings) { + if (!(smbioscmd = qemuBuildSmbiosOEMStringsStr(source->oemStrings))) + return -1; + + virCommandAddArgList(cmd, "-smbios", smbioscmd, NULL); + VIR_FREE(smbioscmd); + } } return 0; diff --git a/src/util/virsysinfo.c b/src/util/virsysinfo.c index ab81b1f7f0..0ad3e6c70d 100644 --- a/src/util/virsysinfo.c +++ b/src/util/virsysinfo.c @@ -106,6 +106,18 @@ void virSysinfoBaseBoardDefClear(virSysinfoBaseBoardDefPtr def) VIR_FREE(def->location); } +void virSysinfoOEMStringsDefFree(virSysinfoOEMStringsDefPtr def) +{ + size_t i; + + if (def == NULL) + return; + + for (i = 0; i < def->nvalues; i++) + VIR_FREE(def->values[i]); + VIR_FREE(def->values); +} + /** * virSysinfoDefFree: * @def: a sysinfo structure @@ -155,6 +167,8 @@ void virSysinfoDefFree(virSysinfoDefPtr def) } VIR_FREE(def->memory); + virSysinfoOEMStringsDefFree(def->oemStrings); + VIR_FREE(def); } @@ -1263,6 +1277,24 @@ virSysinfoMemoryFormat(virBufferPtr buf, virSysinfoDefPtr def) } } +static void +virSysinfoOEMStringsFormat(virBufferPtr buf, virSysinfoOEMStringsDefPtr def) +{ + size_t i; + + if (!def) + return; + + virBufferAddLit(buf, "<oemStrings>\n"); + virBufferAdjustIndent(buf, 2); + for (i = 0; i < def->nvalues; i++) { + virBufferEscapeString(buf, "<entry>%s</entry>\n", + def->values[i]); + } + virBufferAdjustIndent(buf, -2); + virBufferAddLit(buf, "</oemStrings>\n"); +} + /** * virSysinfoFormat: * @buf: buffer to append output to (may use auto-indentation) @@ -1293,6 +1325,7 @@ virSysinfoFormat(virBufferPtr buf, virSysinfoDefPtr def) virSysinfoBaseBoardFormat(&childrenBuf, def->baseBoard, def->nbaseBoard); virSysinfoProcessorFormat(&childrenBuf, def); virSysinfoMemoryFormat(&childrenBuf, def); + virSysinfoOEMStringsFormat(&childrenBuf, def->oemStrings); virBufferAsprintf(buf, "<sysinfo type='%s'", type); if (virBufferUse(&childrenBuf)) { diff --git a/src/util/virsysinfo.h b/src/util/virsysinfo.h index 1e51d2cafa..ecb3a36eb8 100644 --- a/src/util/virsysinfo.h +++ b/src/util/virsysinfo.h @@ -98,6 +98,13 @@ struct _virSysinfoBaseBoardDef { /* XXX board type */ }; +typedef struct _virSysinfoOEMStringsDef virSysinfoOEMStringsDef; +typedef virSysinfoOEMStringsDef *virSysinfoOEMStringsDefPtr; +struct _virSysinfoOEMStringsDef { + size_t nvalues; + char **values; +}; + typedef struct _virSysinfoDef virSysinfoDef; typedef virSysinfoDef *virSysinfoDefPtr; struct _virSysinfoDef { @@ -114,6 +121,8 @@ struct _virSysinfoDef { size_t nmemory; virSysinfoMemoryDefPtr memory; + + virSysinfoOEMStringsDefPtr oemStrings; }; virSysinfoDefPtr virSysinfoRead(void); @@ -121,6 +130,7 @@ virSysinfoDefPtr virSysinfoRead(void); void virSysinfoBIOSDefFree(virSysinfoBIOSDefPtr def); void virSysinfoSystemDefFree(virSysinfoSystemDefPtr def); void virSysinfoBaseBoardDefClear(virSysinfoBaseBoardDefPtr def); +void virSysinfoOEMStringsDefFree(virSysinfoOEMStringsDefPtr def); void virSysinfoDefFree(virSysinfoDefPtr def); int virSysinfoFormat(virBufferPtr buf, virSysinfoDefPtr def) diff --git a/tests/qemuxml2argvdata/qemuxml2argv-smbios.args b/tests/qemuxml2argvdata/qemuxml2argv-smbios.args index 3d94a109f9..d27d436a3a 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-smbios.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-smbios.args @@ -17,6 +17,8 @@ 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' \ +-smbios 'type=11,value=Hello,value=World,value=This is,,\ + more tricky value=escaped' \ -nographic \ -nodefaults \ -chardev socket,id=charmonitor,path=/tmp/lib/domain--1-QEMUGuest1/monitor.sock,\ diff --git a/tests/qemuxml2argvdata/qemuxml2argv-smbios.xml b/tests/qemuxml2argvdata/qemuxml2argv-smbios.xml index c12477dcb5..319bdf61df 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-smbios.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-smbios.xml @@ -26,6 +26,11 @@ <entry name='asset'>CZC1065993</entry> <entry name='location'>Upside down</entry> </baseBoard> + <oemStrings> + <entry>Hello</entry> + <entry>World</entry> + <entry>This is, more tricky value=escaped</entry> + </oemStrings> </sysinfo> <os> <type arch='i686' machine='pc'>hvm</type> diff --git a/tests/qemuxml2xmloutdata/qemuxml2xmlout-smbios.xml b/tests/qemuxml2xmloutdata/qemuxml2xmlout-smbios.xml index d21f6275f0..cbe616c7da 100644 --- a/tests/qemuxml2xmloutdata/qemuxml2xmlout-smbios.xml +++ b/tests/qemuxml2xmloutdata/qemuxml2xmlout-smbios.xml @@ -26,6 +26,11 @@ <entry name='asset'>CZC1065993</entry> <entry name='location'>Upside down</entry> </baseBoard> + <oemStrings> + <entry>Hello</entry> + <entry>World</entry> + <entry>This is, more tricky value=escaped</entry> + </oemStrings> </sysinfo> <os> <type arch='i686' machine='pc'>hvm</type> -- 2.14.3

2 2

[libvirt] [PATCH 0/3] Couple of improvements
by Michal Privoznik 23 Nov '17

23 Nov '17

*** BLURB HERE *** Michal Privoznik (3): vsh: Make self-test more robust tools: Set CFLAGS for wireshark properly tools: Enable warnings for more binaries/libs tools/Makefile.am | 19 ++++++++++--------- tools/vsh.c | 29 ++++++++++++++++++++++------- 2 files changed, 32 insertions(+), 16 deletions(-) -- 2.13.6

3 10

[libvirt] [PATCH] nodedev: Restore setting of privileged
by John Ferlan 23 Nov '17

23 Nov '17

Commit id '36555364' removed the setting of the driver->privileged, which the udevProcessPCI would need in order to read the PCI device configs. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- Not quite sure after seeing other issues how I missed this during review of the series to change the udev nodedev code to use a thread. I tripped across this while "investigating" a recurring issue I'm having with the udev code in an avocado nwfilter test where during a libvirtd restart the udev initialization "hangs" and cannot be killed resulting in a <defunct> process and the only recovery is reboot. Still trying to hack through that, but figured this should go into 3.10 at least. So far only 3.9 would be affected, but only to not get PCI device details. src/node_device/node_device_udev.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 35df13b153..1e1b71742b 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -1933,6 +1933,8 @@ nodeStateInitialize(bool privileged, return -1; } + driver->privileged = privileged; + if (!(driver->devs = virNodeDeviceObjListNew()) || !(priv = udevEventDataNew())) goto cleanup; -- 2.13.6

2 2

[libvirt] [PATCH 0/4] Convert virStoragePoolObj into virObjectLockable
by John Ferlan 23 Nov '17

23 Nov '17

Next in the push to get the storage pool objects to be more common is to use the virObjectLockable for the Pool objects. The patches describe the transformation. John Ferlan (4): storage: Introduce virStoragePoolObjEndAPI storage: Introduce virStoragePoolObjListForEach storage: Introduce virStoragePoolObjListSearch storage: Convert virStoragePoolObj into virObjectLockable src/conf/virstorageobj.c | 194 +++++++++++----- src/conf/virstorageobj.h | 27 ++- src/libvirt_private.syms | 5 +- src/storage/storage_backend_scsi.c | 2 +- src/storage/storage_driver.c | 446 +++++++++++++++++++------------------ src/test/test_driver.c | 158 +++++++------ tests/storagevolxml2argvtest.c | 4 +- 7 files changed, 476 insertions(+), 360 deletions(-) -- 2.13.6

2 10

[libvirt] [PATCH 0/3] qemu: Fix error reporting from QEMU log
by Jiri Denemark 23 Nov '17

23 Nov '17

Jiri Denemark (3): qemu: Properly skip "char device redirected to" in QEMU log vierror: Define VIR_ERROR_MAX_LENGTH macro qemu: Use the end of QEMU log for reporting errors src/qemu/qemu_process.c | 36 +++++++++++++++++++++++++++++++----- src/util/virerror.c | 6 +++--- src/util/virerror.h | 2 ++ 3 files changed, 36 insertions(+), 8 deletions(-) -- 2.15.0

2 4

[libvirt] [PATCH v2 0/5] qemu: Support setting NUMA distances
by Michal Privoznik 23 Nov '17

23 Nov '17

diff to v1: - Renamed & simplified function in 2/5 - Other small nits fixed as raised in review Michal Privoznik (5): virDomainNumaGetNodeDistance: Fix input arguments validation numa: Introduce virDomainNumaNodeDistanceIsUsingDefaults qemu_capabilities: Introcude QEMU_CAPS_NUMA_DIST qemu: Support setting NUMA distances news: Document which drivers support NUMA distances docs/formatdomain.html.in | 2 +- docs/news.xml | 2 +- src/conf/numa_conf.c | 25 ++++++++- src/conf/numa_conf.h | 4 ++ src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 5 ++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 39 ++++++++++++- .../caps_2.10.0-gicv2.aarch64.xml | 1 + .../caps_2.10.0-gicv3.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml | 1 + .../qemuxml2argv-numatune-distances.args | 63 +++++++++++++++++++++ .../qemuxml2argv-numatune-distances.xml | 65 ++++++++++++++++++++++ tests/qemuxml2argvtest.c | 2 + 16 files changed, 209 insertions(+), 5 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-distances.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-distances.xml -- 2.13.6

2 6

[libvirt] Speak at FOSDEM18 Virt & IaaS Devroom!
by Stefan Hajnoczi 23 Nov '17

23 Nov '17

FOSDEM 2018 will be held in Brussels, Belgium on February 3 & 4, 2018. The Virt & Iaas Devroom is hosting talks on KVM, Libvirt, QEMU, OpenStack, and more. The submission deadline for talks is 1 December 2017. See the Call For Papers below for details. I hope to see you there! Stefan --- I am excited to announce that the call for proposals is now open for the Virtualization & IaaS devroom at the upcoming FOSDEM 2018, to be hosted on February 3 and 4, 2018. This year will mark FOSDEM’s 18th anniversary as one of the longest-running free and open source software developer events, attracting thousands of developers and users from all over the world. FOSDEM will be held once again in Brussels, Belgium, on February 3 & 4, 2018. This devroom is a collaborative effort, and is organized by dedicated folks from projects such as OpenStack, Xen Project, oVirt, QEMU, KVM, libvirt, and Foreman. We would like to invite all those who are involved in these fields to submit your proposals by December 1st, 2017. About the Devroom The Virtualization & IaaS devroom will feature session topics such as open source hypervisors and virtual machine managers such as Xen Project, KVM, bhyve, and VirtualBox, and Infrastructure-as-a-Service projects such as Apache CloudStack, OpenStack, oVirt, QEMU, OpenNebula, and Ganeti. This devroom will host presentations that focus on topics of shared interest, such as KVM; libvirt; shared storage; virtualized networking; cloud security; clustering and high availability; interfacing with multiple hypervisors; hyperconverged deployments; and scaling across hundreds or thousands of servers. Presentations in this devroom will be aimed at developers working on these platforms who are looking to collaborate and improve shared infrastructure or solve common problems. We seek topics that encourage dialog between projects and continued work post-FOSDEM. Important Dates Submission deadline: 01 December 2017 Acceptance notifications: 14 December 2017 Final schedule announcement: 21 December 2017 Devroom: 03 and 04 February 2018 (two days- different rooms) Submit Your Proposal All submissions must be made via the Pentabarf event planning site[1]. If you have not used Pentabarf before, you will need to create an account. If you submitted proposals for FOSDEM in previous years, you can use your existing account. After creating the account, select Create Event to start the submission process. Make sure to select Virtualization and IaaS devroom from the Track list. Please fill out all the required fields, and provide a meaningful abstract and description of your proposed session. Submission Guidelines We expect more proposals than we can possibly accept, so it is vitally important that you submit your proposal on or before the deadline. Late submissions are unlikely to be considered. All presentation slots are 45 minutes, with 35 minutes planned for presentations, and 10 minutes for Q&A. All presentations will be recorded and made available under Creative Commons licenses. In the Submission notes field, please indicate that you agree that your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your presentation recorded. For example: "If my presentation is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, <NAME>." In the Submission notes field, please also confirm that if your talk is accepted, you will be able to attend FOSDEM and deliver your presentation. We will not consider proposals from prospective speakers who are unsure whether they will be able to secure funds for travel and lodging to attend FOSDEM. (Sadly, we are not able to offer travel funding for prospective speakers.) Speaker Mentoring Program As a part of the rising efforts to grow our communities and encourage a diverse and inclusive conference ecosystem, we're happy to announce that we'll be offering mentoring for new speakers. Our mentors can help you with tasks such as reviewing your abstract, reviewing your presentation outline or slides, or practicing your talk with you. You may apply to the mentoring program as a newcomer speaker if you: Never presented before or Presented only lightning talks or Presented full-length talks at small meetups (<50 ppl) Submission Guidelines Mentored presentations will have 25-minute slots, where 20 minutes will include the presentation and 5 minutes will be reserved for questions. The number of newcomer session slots is limited, so we will probably not be able to accept all applications. You must submit your talk and abstract to apply for the mentoring program, our mentors are volunteering their time and will happily provide feedback but won't write your presentation for you! If you are experiencing problems with Pentabarf, the proposal submission interface, or have other questions, you can email our devroom mailing list[2] and we will try to help you. How to Apply In addition to agreeing to video recording and confirming that you can attend FOSDEM in case your session is accepted, please write "speaker mentoring program application" in the "Submission notes" field, and list any prior speaking experience or other relevant information for your application. Call for Mentors Interested in mentoring newcomer speakers? We'd love to have your help! Please email iaas-virt-devroom at lists.fosdem.org with a short speaker biography and any specific fields of expertise (for example, KVM, OpenStack, storage, etc.) so that we can match you with a newcomer speaker from a similar field. Estimated time investment can be as low as a 5-10 hours in total, usually distributed weekly or bi-weekly. Never mentored a newcomer speaker but interested to try? As the mentoring program coordinator, email Brian Proffitt[3] and he will be happy to answer your questions! Code of Conduct Following the release of the updated code of conduct for FOSDEM, we'd like to remind all speakers and attendees that all of the presentations and discussions in our devroom are held under the guidelines set in the CoC and we expect attendees, speakers, and volunteers to follow the CoC at all times. If you submit a proposal and it is accepted, you will be required to confirm that you accept the FOSDEM CoC. If you have any questions about the CoC or wish to have one of the devroom organizers review your presentation slides or any other content for CoC compliance, please email us and we will do our best to assist you. Call for Volunteers We are also looking for volunteers to help run the devroom. We need assistance watching time for the speakers, and helping with video for the devroom. Please contact me, Brian Proffitt, for more information. Questions? If you have any questions about this devroom, please send your questions to our devroom mailing list. You can also subscribe to the list to receive updates about important dates, session announcements, and to connect with other attendees. See you all at FOSDEM! [1] <https://penta.fosdem.org/submission/FOSDEM18> https://penta.fosdem.org/submission/FOSDEM18 [2] iaas-virt-devroom at lists.fosdem.org <https://lists.fosdem.org/listinfo/fosdem> [3] bkp at redhat.com

1 0

[libvirt] [PATCH] util: Fix leak in virStringTrimOptionalNewline
by Martin Kletzander 23 Nov '17

23 Nov '17

Do not access any data if strlen() == 0. Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- src/util/virstring.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/src/util/virstring.c b/src/util/virstring.c index eac4774b533e..b2ebce27ff49 100644 --- a/src/util/virstring.c +++ b/src/util/virstring.c @@ -1394,9 +1394,13 @@ virStringEncodeBase64(const uint8_t *buf, size_t buflen) */ void virStringTrimOptionalNewline(char *str) { - char *tmp = str + strlen(str) - 1; - if (*tmp == '\n') - *tmp = '\0'; + size_t len = strlen(str); + + if (!len) + return; + + if (str[len - 1] == '\n') + str[len - 1] = '\0'; } -- 2.15.0

2 1

[libvirt] [PATCH v2 0/9] qemu: command: Refactor handling of disk drive arguments (blockdev-add saga)
by Peter Krempa 22 Nov '17

22 Nov '17

Version 2 only prepares for the move of the arguments to -device which will be used together with -blockdev rather than switching right away. This will prevent breaking old qemu support since individual parameters were moved to -device in separate instances. Peter Krempa (9): qemu: command: Split out geometry frontend attribute formatting from -drive tests: qemuxml2xml: Run the 'disk-serial' test tests: qemuxml2argv: Test SD card with serial number qemu: command: Move disk 'serial' into frontend parameter formatter qemu: command: Move around order of generating -drive arguments qemu: command: Refactor logic when formatting -drive qemu: command: Move disk trhottling argument building into a separate function qemu: command: Move formatting of disk io error policy from -drive qemu: command: Anotate formatting of the frontend attributes with -drive src/qemu/qemu_command.c | 241 ++++++++++++--------- .../qemuxml2argvdata/qemuxml2argv-boot-cdrom.args | 2 +- .../qemuxml2argv-boot-complex-bootindex.args | 2 +- .../qemuxml2argv-boot-complex.args | 2 +- ...xml2argv-boot-menu-disable-drive-bootindex.args | 2 +- .../qemuxml2argv-boot-menu-disable-drive.args | 2 +- .../qemuxml2argv-boot-menu-disable.args | 2 +- .../qemuxml2argv-boot-menu-enable-bootindex.args | 2 +- ...qemuxml2argv-boot-menu-enable-with-timeout.args | 2 +- .../qemuxml2argv-boot-menu-enable.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-boot-multi.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-boot-order.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-boot-strict.args | 2 +- .../qemuxml2argv-controller-order.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-disk-aio.args | 4 +- .../qemuxml2argv-disk-cdrom-empty.args | 2 +- .../qemuxml2argv-disk-cdrom-network-ftp.args | 2 +- .../qemuxml2argv-disk-cdrom-network-ftps.args | 2 +- .../qemuxml2argv-disk-cdrom-network-http.args | 2 +- .../qemuxml2argv-disk-cdrom-network-https.args | 2 +- .../qemuxml2argv-disk-cdrom-network-tftp.args | 2 +- ...qemuxml2argv-disk-cdrom-tray-no-device-cap.args | 2 +- .../qemuxml2argv-disk-cdrom-tray.args | 4 +- .../qemuxml2argvdata/qemuxml2argv-disk-cdrom.args | 2 +- .../qemuxml2argv-disk-copy_on_read.args | 2 +- .../qemuxml2argv-disk-drive-boot-cdrom.args | 4 +- .../qemuxml2argv-disk-drive-boot-disk.args | 4 +- .../qemuxml2argv-disk-drive-cache-directsync.args | 4 +- .../qemuxml2argv-disk-drive-cache-unsafe.args | 4 +- .../qemuxml2argv-disk-drive-cache-v2-none.args | 4 +- .../qemuxml2argv-disk-drive-cache-v2-wb.args | 4 +- .../qemuxml2argv-disk-drive-cache-v2-wt.args | 4 +- .../qemuxml2argv-disk-drive-detect-zeroes.args | 2 +- .../qemuxml2argv-disk-drive-discard.args | 2 +- ...uxml2argv-disk-drive-error-policy-enospace.args | 6 +- .../qemuxml2argv-disk-drive-error-policy-stop.args | 6 +- ...gv-disk-drive-error-policy-wreport-rignore.args | 6 +- .../qemuxml2argv-disk-drive-fmt-qcow.args | 4 +- .../qemuxml2argv-disk-drive-no-boot.args | 4 +- .../qemuxml2argv-disk-drive-readonly-disk.args | 2 +- ...qemuxml2argv-disk-drive-readonly-no-device.args | 2 +- .../qemuxml2argv-disk-drive-shared.args | 4 +- .../qemuxml2argv-disk-ioeventfd.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-disk-order.args | 4 +- .../qemuxml2argvdata/qemuxml2argv-disk-serial.args | 1 + .../qemuxml2argvdata/qemuxml2argv-disk-serial.xml | 5 + .../qemuxml2argv-disk-snapshot.args | 4 +- .../qemuxml2argv-disk-source-pool-mode.args | 12 +- .../qemuxml2argv-disk-source-pool.args | 4 +- .../qemuxml2argvdata/qemuxml2argv-disk-virtio.args | 4 +- tests/qemuxml2argvdata/qemuxml2argv-event_idx.args | 2 +- .../qemuxml2argv-graphics-spice-timeout.args | 2 +- .../qemuxml2argv-hugepages-numa.args | 2 +- .../qemuxml2argv-pci-autoadd-addr.args | 4 +- .../qemuxml2argv-pci-autoadd-idx.args | 4 +- .../qemuxml2argv-pci-autofill-addr.args | 4 +- .../qemuxml2argvdata/qemuxml2argv-pci-bridge.args | 4 +- tests/qemuxml2argvdata/qemuxml2argv-pci-many.args | 4 +- .../qemuxml2argv-user-aliases.args | 2 +- .../qemuxml2xmlout-disk-serial.xml | 47 ++++ tests/qemuxml2xmltest.c | 2 + 61 files changed, 280 insertions(+), 192 deletions(-) create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-serial.xml -- 2.14.3

2 10

[libvirt] [PATCH] qemu: domain: Don't call namespace setup for storage already accessed by vm
by Peter Krempa 22 Nov '17

22 Nov '17

When doing block commit we need to allow write for members of the backing chain so that we can commit the data into them. qemuDomainDiskChainElementPrepare was used for this which since commit 786d8d91b4 calls qemuDomainNamespaceSetupDisk which has very adverse side-effects, namely it relabels the nodes to the same label it has in the main namespace. This was messing up permissions for the commit operation since its touching various parts of a single backing chain. Since we are are actually not introducing new images at that point add a flag for qemuDomainDiskChainElementPrepare which will refrain from calling to the namespace setup function. Calls from qemuDomainSnapshotCreateSingleDiskActive and qemuDomainBlockCopyCommon do introduce new members all calls from qemuDomainBlockCommit do not, so the calls are anotated accordingly. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1506072 --- src/qemu/qemu_domain.c | 17 ++++++++++++++--- src/qemu/qemu_domain.h | 3 ++- src/qemu/qemu_driver.c | 12 ++++++------ 3 files changed, 22 insertions(+), 10 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index cc7596bad1..f12450cc69 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -6146,15 +6146,25 @@ qemuDomainDiskChainElementRevoke(virQEMUDriverPtr driver, /** * qemuDomainDiskChainElementPrepare: + * @driver: qemu driver data + * @vm: domain object + * @elem: source structure to set access for + * @readonly: setup read-only access if true + * @newSource: @elem describes a storage source which @vm can't access yet * * Allow a VM access to a single element of a disk backing chain; this helper * ensures that the lock manager, cgroup device controller, and security manager - * labelling are all aware of each new file before it is added to a chain */ + * labelling are all aware of each new file before it is added to a chain. + * + * When modifying permissions of @elem which @vm can already access (is in the + * backing chain) @newSource needs to be set to false. + */ int qemuDomainDiskChainElementPrepare(virQEMUDriverPtr driver, virDomainObjPtr vm, virStorageSourcePtr elem, - bool readonly) + bool readonly, + bool newSource) { bool was_readonly = elem->readonly; virQEMUDriverConfigPtr cfg = NULL; @@ -6167,7 +6177,8 @@ qemuDomainDiskChainElementPrepare(virQEMUDriverPtr driver, if (virDomainLockImageAttach(driver->lockManager, cfg->uri, vm, elem) < 0) goto cleanup; - if (qemuDomainNamespaceSetupDisk(driver, vm, elem) < 0) + if (newSource && + qemuDomainNamespaceSetupDisk(driver, vm, elem) < 0) goto cleanup; if (qemuSetupImageCgroup(vm, elem) < 0) diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h index e021da51fc..9066f5d0f5 100644 --- a/src/qemu/qemu_domain.h +++ b/src/qemu/qemu_domain.h @@ -689,7 +689,8 @@ void qemuDomainDiskChainElementRevoke(virQEMUDriverPtr driver, int qemuDomainDiskChainElementPrepare(virQEMUDriverPtr driver, virDomainObjPtr vm, virStorageSourcePtr elem, - bool readonly); + bool readonly, + bool newSource); int qemuDomainCleanupAdd(virDomainObjPtr vm, qemuDomainCleanupCallback cb); diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 3a0e3b6cec..809863be57 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -14570,7 +14570,7 @@ qemuDomainSnapshotCreateSingleDiskActive(virQEMUDriverPtr driver, } /* set correct security, cgroup and locking options on the new image */ - if (qemuDomainDiskChainElementPrepare(driver, vm, dd->src, false) < 0) { + if (qemuDomainDiskChainElementPrepare(driver, vm, dd->src, false, true) < 0) { qemuDomainDiskChainElementRevoke(driver, vm, dd->src); goto cleanup; } @@ -17165,7 +17165,7 @@ qemuDomainBlockCopyCommon(virDomainObjPtr vm, keepParentLabel) < 0) goto endjob; - if (qemuDomainDiskChainElementPrepare(driver, vm, mirror, false) < 0) { + if (qemuDomainDiskChainElementPrepare(driver, vm, mirror, false, true) < 0) { qemuDomainDiskChainElementRevoke(driver, vm, mirror); goto endjob; } @@ -17558,9 +17558,9 @@ qemuDomainBlockCommit(virDomainPtr dom, * operation succeeds, but doing that requires tracking the * operation in XML across libvirtd restarts. */ clean_access = true; - if (qemuDomainDiskChainElementPrepare(driver, vm, baseSource, false) < 0 || + if (qemuDomainDiskChainElementPrepare(driver, vm, baseSource, false, false) < 0 || (top_parent && top_parent != disk->src && - qemuDomainDiskChainElementPrepare(driver, vm, top_parent, false) < 0)) + qemuDomainDiskChainElementPrepare(driver, vm, top_parent, false, false) < 0)) goto endjob; /* Start the commit operation. Pass the user's original spelling, @@ -17604,9 +17604,9 @@ qemuDomainBlockCommit(virDomainPtr dom, if (ret < 0 && clean_access) { virErrorPtr orig_err = virSaveLastError(); /* Revert access to read-only, if possible. */ - qemuDomainDiskChainElementPrepare(driver, vm, baseSource, true); + qemuDomainDiskChainElementPrepare(driver, vm, baseSource, true, false); if (top_parent && top_parent != disk->src) - qemuDomainDiskChainElementPrepare(driver, vm, top_parent, true); + qemuDomainDiskChainElementPrepare(driver, vm, top_parent, true, false); if (orig_err) { virSetError(orig_err); -- 2.14.3

2 1