- Devel - libvirt List Archives

[libvirt] [PATCH v3] util: Block SIGPIPE until execve in child process
by Wang Yechao 18 Oct '19

18 Oct '19

Libvirtd has set SIGPIPE to ignored, and virFork resets all signal handlers to the defaults. But child process may write logs to stderr/stdout, that may generate SIGPIPE if journald has stopped. So block SIGPIPE in virFork, and unblock it before execve. Signed-off-by: Wang Yechao <wang.yechao255(a)zte.com.cn> --- v1 patch: https://www.redhat.com/archives/libvir-list/2019-October/msg00720.html Changes in v2: - use pthread_sigmask to block SIGPIPE Changes in v3: - pass SIG_UNBLOCK(not SIG_SETMASK) to pthread_sigmask when unlock SIGPIPE --- src/util/vircommand.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/util/vircommand.c b/src/util/vircommand.c index 79e1e87..bd3a582 100644 --- a/src/util/vircommand.c +++ b/src/util/vircommand.c @@ -321,6 +321,15 @@ virFork(void) virDispatchError(NULL); _exit(EXIT_CANCELED); } + + sigemptyset(&newmask); + sigaddset(&newmask, SIGPIPE); + if (pthread_sigmask(SIG_BLOCK, &newmask, NULL) != 0) { + virReportSystemError(errno, "%s", _("cannot block SIGPIPE")); + virDispatchError(NULL); + _exit(EXIT_CANCELED); + } + } return pid; } @@ -553,6 +562,7 @@ virExec(virCommandPtr cmd) struct sigaction waxon, waxoff; VIR_AUTOFREE(gid_t *) groups = NULL; int ngroups; + sigset_t set; if (cmd->args[0][0] != '/') { if (!(binary = binarystr = virFindFileInPath(cmd->args[0]))) { @@ -792,6 +802,13 @@ virExec(virCommandPtr cmd) /* Close logging again to ensure no FDs leak to child */ virLogReset(); + sigemptyset(&set); + sigaddset(&set, SIGPIPE); + if (pthread_sigmask(SIG_UNBLOCK, &set, NULL) != 0) { + virReportSystemError(errno, "%s", _("cannot unblock SIGPIPE")); + goto fork_error; + } + if (cmd->env) execve(binary, cmd->args, cmd->env); else -- 1.8.3.1

4 8

[libvirt] [PATCH v3 0/4] qemu_process.c: GLib powered cleanup
by Daniel Henrique Barboza 17 Oct '19

17 Oct '19

changes from v2: - only use GLib macros - split the patches to separate the 'remove cleanup labels' patch from the most trivial stuff - added a new patch to change virAsprintf to g_stdup_printf v2: https://www.redhat.com/archives/libvir-list/2019-October/msg00929.html v1: https://www.redhat.com/archives/libvir-list/2019-September/msg01465.html Daniel Henrique Barboza (4): qemu_process.c: use g_autofree qemu_process.c: use g_autoptr() qemu_process.c: remove cleanup labels after g_auto*() changes qemu_process.c: use g_strdup_printf src/qemu/qemu_process.c | 449 +++++++++++++++------------------------- 1 file changed, 166 insertions(+), 283 deletions(-) -- 2.21.0

2 7

[libvirt] [PULL v2 00/19] Bitmaps patches
by John Snow 17 Oct '19

17 Oct '19

The following changes since commit c760cb77e511eb05094df67c1b30029a952efa35: Merge remote-tracking branch 'remotes/dgilbert/tags/pull-migration-20191011a' into staging (2019-10-14 16:09:52 +0100) are available in the Git repository at: https://github.com/jnsnow/qemu.git tags/bitmaps-pull-request for you to fetch changes up to b2ca29ee390743c42a6062d44ee3b10fb51f9fa6: dirty-bitmaps: remove deprecated autoload parameter (2019-10-14 15:28:17 -0400) ---------------------------------------------------------------- Pull request ---------------------------------------------------------------- John Snow (2): MAINTAINERS: Add Vladimir as a reviewer for bitmaps dirty-bitmaps: remove deprecated autoload parameter Vladimir Sementsov-Ogievskiy (17): util/hbitmap: strict hbitmap_reset block: move bdrv_can_store_new_dirty_bitmap to block/dirty-bitmap.c block/dirty-bitmap: return int from bdrv_remove_persistent_dirty_bitmap block/qcow2: proper locking on bitmap add/remove paths block/dirty-bitmap: drop meta block/dirty-bitmap: add bs link block/dirty-bitmap: drop BdrvDirtyBitmap.mutex block/dirty-bitmap: refactor bdrv_dirty_bitmap_next block: switch reopen queue from QSIMPLEQ to QTAILQ block: reverse order for reopen commits iotests: add test-case to 165 to test reopening qcow2 bitmaps to RW block/qcow2-bitmap: get rid of bdrv_has_changed_persistent_bitmaps block/qcow2-bitmap: drop qcow2_reopen_bitmaps_rw_hint() block/qcow2-bitmap: do not remove bitmaps on reopen-ro iotests: add test 260 to check bitmap life after snapshot + commit block/qcow2-bitmap: fix and improve qcow2_reopen_bitmaps_rw qcow2-bitmap: move bitmap reopen-rw code to qcow2_reopen_commit qemu-deprecated.texi | 20 ++- qapi/block-core.json | 6 +- block/qcow2.h | 19 +-- include/block/block.h | 2 +- include/block/block_int.h | 20 +-- include/block/dirty-bitmap.h | 34 ++-- include/qemu/hbitmap.h | 5 + block.c | 79 +++------ block/backup.c | 8 +- block/block-copy.c | 2 +- block/dirty-bitmap.c | 290 +++++++++++++++++++-------------- block/mirror.c | 4 +- block/qcow2-bitmap.c | 212 +++++++++++++++--------- block/qcow2.c | 22 ++- blockdev.c | 40 ++--- migration/block-dirty-bitmap.c | 11 +- migration/block.c | 4 +- tests/test-hbitmap.c | 2 +- util/hbitmap.c | 4 + MAINTAINERS | 3 +- tests/qemu-iotests/165 | 57 ++++++- tests/qemu-iotests/165.out | 4 +- tests/qemu-iotests/260 | 89 ++++++++++ tests/qemu-iotests/260.out | 52 ++++++ tests/qemu-iotests/group | 1 + 25 files changed, 623 insertions(+), 367 deletions(-) create mode 100755 tests/qemu-iotests/260 create mode 100644 tests/qemu-iotests/260.out -- 2.21.0

2 21

[libvirt] [PATCH] qemu: caps: Use unique key for domCaps caching
by Cole Robinson 17 Oct '19

17 Oct '19

When searching qemuCaps->domCapsCache for existing domCaps data, we check for a matching pair of arch+virttype+machine+emulator. However for the hash table key we only use the machine string. So if the cache already contains: x86_64 + kvm + pc + /usr/bin/qemu-kvm But a new VM is defined with x86_64 + qemu + pc + /usr/bin/qemu-kvm We correctly fail to find matching cached domCaps, but then attempt to use a colliding key with virHashAddEntry Fix this by building a hash key from the 4 values, not just machine Signed-off-by: Cole Robinson <crobinso(a)redhat.com> --- qemu_domain.c validation should be affected, but it is covered up by another bug, fixed here: https://www.redhat.com/archives/libvir-list/2019-October/msg00708.html src/qemu/qemu_conf.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index 08cd784054..64ac8cbdd3 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -1396,6 +1396,8 @@ virQEMUDriverGetDomainCapabilities(virQEMUDriverPtr driver, domCaps = virHashSearch(domCapsCache, virQEMUDriverSearchDomcaps, &data, NULL); if (!domCaps) { + VIR_AUTOFREE(char *) key = NULL; + /* hash miss, build new domcaps */ if (!(domCaps = virDomainCapsNew(data.path, data.machine, data.arch, data.virttype))) @@ -1406,7 +1408,14 @@ virQEMUDriverGetDomainCapabilities(virQEMUDriverPtr driver, cfg->firmwares, cfg->nfirmwares) < 0) return NULL; - if (virHashAddEntry(domCapsCache, machine, domCaps) < 0) + if (virAsprintf(&key, "%d:%d:%s:%s", + data.arch, + data.virttype, + NULLSTR(data.machine), + NULLSTR(data.path)) < 0) + return NULL; + + if (virHashAddEntry(domCapsCache, key, domCaps) < 0) return NULL; } -- 2.23.0

3 3

[libvirt] [Call for Presentations] FOSDEM 2020 Virtualization & IaaS Devroom
by Kashyap Chamarthy 17 Oct '19

17 Oct '19

The FOSDEM open source developer conference is taking place in Brussels, Belgium on February 1st & 2nd, 2020. The call for virtualization presentations has been posted[1]. Reposting the text here (formatted for readability): ----------------------------------------------------------------------- We are excited to announce that the call for proposals is now open for the Virtualization & IaaS devroom at the upcoming FOSDEM 2020, to be hosted on February 1st 2020. The year 2020 will mark FOSDEM’s 20th 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 1st & 2nd, 2020. This devroom is a collaborative effort, and is organized by dedicated folks from projects such as OpenStack, Xen Project, oVirt, QEMU, KVM, libvirt, Foreman, and virtualization-related projects. We would like to invite all those who are involved in these fields to submit your proposals by December 1st, 2019. Important Dates --------------- - Submission deadline: 1 December 2019 - Acceptance notifications: 10 December 2019 - Final schedule announcement: 15th December 2019 - Devroom is only on one day: 1st February 2020 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, QEMU, bhyve, and VirtualBox, and Infrastructure-as-a-Service projects such as KubeVirt, Apache CloudStack, OpenStack, oVirt, QEMU and OpenNebula. This devroom will host presentations that focus on topics of shared interest, such as KVM; QEMU; 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. 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 30 minutes, with 20 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) 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. 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 devroom mailing list [2] 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://lists.fosdem.org/pipermail/fosdem/2019q4/002889.html -- /kashyap

1 0

[libvirt] [RFC] Accepting PRs/MRs for libvirt on GitHub/GitLab
by Andrea Bolognani 17 Oct '19

17 Oct '19

As we look to make the libvirt project easier to contribute to, one fact that certainly comes to mind is that we only accept patches via the mailing list. While the core developers are comfortable with the email-based workflow and swear by it, many perspective contributors are used to the PR/MR workflow common to many Open Source projects these days, and similarly swear by it. If we look at the PRs submitted on GitHub against the libvirt mirror repository[1], there's just three of them per year on average, which is arguably not a lot; however, it should be noted that each repository also carries a fairly loud "PULL REQUESTS ARE IGNORED" message right at the top, and it's not unlikely that a number of perspective contributors simply lost interest after seeing it. As a way to make contributions easier without forcing core developers to give up their current workflow or making the project dependent on a third-party provider, I suggest we adopt a hybrid approach. First of all, we'd remove the ominous message from GitHub mirror repositories (interestingly, the same is not present on GitLab). Then, we'd starting accepting PRs/MRs. The way we'd handle them is that, when one comes in, one among the handful of core developers who volunteered to do so would review the patches on the respective platform, working with the submitter to get it into shape just like they would do on the mailing list; once the series is finally ready to be merged, the core developer would update the PR/MR as necessary, for example picking up R-bs or fixing the kind of trivial issues that usually don't warrant a repost, and then push to master as usual. More in detail: GitHub and GitLab have a feature that allows project members to update PRs/MRs: basically the way it works is that, if the PR/MR was created by the user 'foo' from their branch 'bar', the libvirt developer is allowed to (force-)push to the foo/libvirt/bar branch, and doing so updates the corresponding PR/MR; after that, if the updated branch is locally merged into master and master is pushed to the libvirt.org repo, once it gets mirrored GitHub/GitLab will recognize that the commit IDs match and automatically mark the PR/MR as merged. I have tested this behavior on both platforms (minus the mirroring part) with Martin's help. One last important bit. In the spirit of not requiring core developers to alter their workflow, the developer who reviewed the patches on GitHub/GitLab will also be responsible to format them to the mailing list after merging them: this way, even those who don't have a GitHub/GitLab account will get a chance to take notice of the code changes and weigh in. Unlike what we're used to, this feedback will come after the fact, but assuming that issues are spotted only at that point we can either push the relevant fixes as follow-up commits or even revert the series outright, so I don't feel like it would be a massive problem overall. Thoughts? [1] https://github.com/libvirt/libvirt/pulls?q=is:pr+is:closed -- Andrea Bolognani / Red Hat / Virtualization

8 14

[libvirt] [PATCH 0/2] gitdm: Update configuration
by Andrea Bolognani 17 Oct '19

17 Oct '19

Andrea Bolognani (2): gitdm: Fix sorting gitdm: Add missing entries docs/gitdm/companies/others | 4 +++- docs/gitdm/groups/unaffiliated | 1 + 2 files changed, 4 insertions(+), 1 deletion(-) -- 2.21.0

1 2

[libvirt] [PATCH v1] qemu_driver: improve comparison/baseline error reporting
by Collin Walling 17 Oct '19

17 Oct '19

Providing an erroneous CPU definition in the XML file provided to the hypervisor-cpu-compare/baseline command will result in a verbose internal error. Let's add some sanity checking before executing the QMP commands to provide a cleaner message if something is wrong with the CPU model or features. An internal error will still appear for other messages originating from QEMU e.g. if a newer feature is not available for an older CPU model. Signed-off-by: Collin Walling <walling(a)linux.ibm.com> --- src/qemu/qemu_driver.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 2e422b5..a4f916b 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -13645,6 +13645,52 @@ qemuConnectCompareCPU(virConnectPtr conn, } +static int +qemuConnectCheckCPUModel(qemuMonitorPtr mon, + virCPUDefPtr cpu) +{ + qemuMonitorCPUModelInfoPtr modelInfo = NULL; + qemuMonitorCPUModelExpansionType type; + size_t i, j; + int ret = -1; + + /* Collect CPU model name and features known by QEMU */ + type = QEMU_MONITOR_CPU_MODEL_EXPANSION_FULL; + if (qemuMonitorGetCPUModelExpansion(mon, type, cpu, true, + false, &modelInfo) < 0) + goto cleanup; + + /* Sanity check CPU model */ + if (!modelInfo) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("Unknown CPU model: %s"), cpu->model); + goto cleanup; + } + + /* Sanity check CPU features */ + for (i = 0; i < cpu->nfeatures; i++) { + const char *feat = cpu->features[i].name; + + for (j = 0; j < modelInfo->nprops; j++) { + const char *prop = modelInfo->props[j].name; + if (STREQ(feat, prop)) + break; + } + + if (j == modelInfo->nprops) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("Unknown CPU feature: %s"), feat); + goto cleanup; + } + } + ret = 0; + + cleanup: + qemuMonitorCPUModelInfoFree(modelInfo); + return ret; +} + + static virCPUCompareResult qemuConnectCPUModelComparison(virQEMUCapsPtr qemuCaps, const char *libDir, @@ -13665,6 +13711,11 @@ qemuConnectCPUModelComparison(virQEMUCapsPtr qemuCaps, if (qemuProcessQMPStart(proc) < 0) goto cleanup; + if (qemuConnectCheckCPUModel(proc->mon, cpu_a) < 0 || + qemuConnectCheckCPUModel(proc->mon, cpu_b) < 0) { + goto cleanup; + } + if (qemuMonitorGetCPUModelComparison(proc->mon, cpu_a, cpu_b, &result) < 0) goto cleanup; @@ -13863,6 +13914,9 @@ qemuConnectCPUModelBaseline(virQEMUCapsPtr qemuCaps, if (qemuProcessQMPStart(proc) < 0) goto cleanup; + if (qemuConnectCheckCPUModel(proc->mon, cpus[0]) < 0) + goto cleanup; + if (VIR_ALLOC(baseline) < 0) goto cleanup; @@ -13870,6 +13924,9 @@ qemuConnectCPUModelBaseline(virQEMUCapsPtr qemuCaps, goto cleanup; for (i = 1; i < ncpus; i++) { + if (qemuConnectCheckCPUModel(proc->mon, cpus[i]) < 0) + goto cleanup; + if (qemuMonitorGetCPUModelBaseline(proc->mon, baseline, cpus[i], &result) < 0) goto cleanup; -- 2.7.4

2 1

[libvirt] [PATCH v4 0/5] qemu_driver: GLib powered cleanup
by Daniel Henrique Barboza 17 Oct '19

17 Oct '19

changes from v3: - only use the new Glib macros in all patches - different patch split, as suggested by Jano in v3 review - patch 5 (new): g_strdup_printf conversion changes from v2: - rebased with newer master (67e72053c1) - added an extra patch to convert the existing VIR_AUTO* macros to g_auto* ones, all at once, to avoid the case where a method will have both VIR_AUTO* and g_auto* macros at the same time. changes from v1: - addressed review concerns made by Erik - added more cleanups, as suggested by Erik v3: https://www.redhat.com/archives/libvir-list/2019-October/msg00918.html v2: https://www.redhat.com/archives/libvir-list/2019-September/msg01452.html v1: https://www.redhat.com/archives/libvir-list/2019-September/msg00719.html Daniel Henrique Barboza (5): qemu_driver: use g_auto* in some functions qemu_driver: use g_autoptr() when possible qemu_driver: use g_autofree when possible qemu_driver: remove unused 'cleanup' labels after g_auto*() changes qemu_driver: use g_strdup_printf src/qemu/qemu_driver.c | 721 ++++++++++++++--------------------------- 1 file changed, 242 insertions(+), 479 deletions(-) -- 2.21.0

5 13

[libvirt] [PATCH 1/1] qemu_hotplug: use VIR_AUTOUNREF() with virConnectPtr
by Daniel Henrique Barboza 17 Oct '19

17 Oct '19

Signed-off-by: Daniel Henrique Barboza <danielhb413(a)gmail.com> --- Checked other pointer types that can be autounref as well, just found these instances. src/qemu/qemu_hotplug.c | 22 ++++++++-------------- 1 file changed, 8 insertions(+), 14 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index e9285f0964..4cab132901 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -1154,7 +1154,7 @@ qemuDomainAttachNetDevice(virQEMUDriverPtr driver, bool charDevPlugged = false; bool netdevPlugged = false; VIR_AUTOFREE(char *) netdev_name = NULL; - virConnectPtr conn = NULL; + VIR_AUTOUNREF(virConnectPtr) conn = NULL; virErrorPtr save_err = NULL; /* preallocate new slot for device */ @@ -1497,7 +1497,6 @@ qemuDomainAttachNetDevice(virQEMUDriverPtr driver, } VIR_FREE(vhostfd); VIR_FREE(vhostfdName); - virObjectUnref(conn); virDomainCCWAddressSetFree(ccwaddrs); VIR_FORCE_CLOSE(slirpfd); @@ -3475,7 +3474,7 @@ qemuDomainChangeNet(virQEMUDriverPtr driver, bool needVlanUpdate = false; int ret = -1; int changeidx = -1; - virConnectPtr conn = NULL; + VIR_AUTOUNREF(virConnectPtr) conn = NULL; virErrorPtr save_err = NULL; if ((changeidx = virDomainNetFindIdx(vm->def, newdev)) < 0) @@ -3919,7 +3918,6 @@ qemuDomainChangeNet(virQEMUDriverPtr driver, */ if (newdev && newdev->type == VIR_DOMAIN_NET_TYPE_NETWORK && conn) virDomainNetReleaseActualDevice(conn, vm->def, newdev); - virObjectUnref(conn); virErrorRestore(&save_err); return ret; @@ -4535,13 +4533,11 @@ qemuDomainRemoveHostDevice(virQEMUDriverPtr driver, if (net) { if (net->type == VIR_DOMAIN_NET_TYPE_NETWORK) { - virConnectPtr conn = virGetConnectNetwork(); - if (conn) { + VIR_AUTOUNREF(virConnectPtr) conn = virGetConnectNetwork(); + if (conn) virDomainNetReleaseActualDevice(conn, vm->def, net); - virObjectUnref(conn); - } else { + else VIR_WARN("Unable to release network device '%s'", NULLSTR(net->ifname)); - } } virDomainNetDefFree(net); } @@ -4641,13 +4637,11 @@ qemuDomainRemoveNetDevice(virQEMUDriverPtr driver, qemuDomainNetDeviceVportRemove(net); if (net->type == VIR_DOMAIN_NET_TYPE_NETWORK) { - virConnectPtr conn = virGetConnectNetwork(); - if (conn) { + VIR_AUTOUNREF(virConnectPtr) conn = virGetConnectNetwork(); + if (conn) virDomainNetReleaseActualDevice(conn, vm->def, net); - virObjectUnref(conn); - } else { + else VIR_WARN("Unable to release network device '%s'", NULLSTR(net->ifname)); - } } virDomainNetDefFree(net); return 0; -- 2.21.0

1 1