- Devel - libvirt List Archives

[libvirt] [PATCH v2 0/2] Fix possible crash when resctrl gets remounted
by Martin Kletzander 05 Feb '18

05 Feb '18

First one just fixes the crash, but the second one makes sure we get consistent info with at least higher probability. Martin Kletzander (2): util: Check if kernel-provided info is consistent with itself qemu: Refresh capabilities when creating resctrl allocation src/qemu/qemu_process.c | 8 +++++++- src/util/virresctrl.c | 11 +++++++++++ 2 files changed, 18 insertions(+), 1 deletion(-) -- 2.16.1

2 8

[libvirt] PATCH add q35 support ide
by Paul Schlacter 04 Feb '18

04 Feb '18

hello everyone: In q35 motherboard use ide, Currently, the qemu has supported q35 Motherboard support ide bus diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index cc7596b..2dbade8 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -7188,6 +7188,7 @@ bool qemuDomainMachineHasBuiltinIDE(const char *machine) { return qemuDomainMachineIsI440FX(machine) || + qemuDomainMachineIsQ35(machine) || STREQ(machine, "malta") || STREQ(machine, "sun4u") || STREQ(machine, "g3beige"); [root@kvm ~]# virsh dumpxml instance-00000004 | grep machine= <type arch='x86_64' machine='pc-q35-rhel7.3.0'>hvm</type> [root@kvm~]# [root@kvm~]# virsh dumpxml instance-00000004 | grep "'disk'" -A 13 <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/nova/instances/288271ce-69eb-4629-b98c- 779036661294/disk'/> <backingStore type='file' index='1'> <format type='raw'/> <source file='/var/lib/nova/instances/_base/ 8d383eef2e628adfc197a6e40e656916de566ab1'/> <backingStore/> </backingStore> <target dev='vda' bus='ide'/> <alias name='ide0-0-0'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk>

3 3

[libvirt] CfP 13th Virtualization in High-Performance Cloud Computing Workshop (VHPC '18)
by VHPC 18 02 Feb '18

02 Feb '18

*====================================================================CALL FOR PAPERS 13th Workshop on Virtualization in High-Performance Cloud Computing (VHPC '18)held in conjunction with the International Supercomputing Conference - High Performance,June 24-28, 2018, Frankfurt, Germany.(Springer LNCS Proceedings) ====================================================================Date: June 28, 2018Workshop URL: http://vhpc.org <http://vhpc.org>Paper Submission Deadline: April 23, 2018, Springer LNCS, rolling abstract submissionAbstract/Paper Submission Link: https://edas.info/newPaper.php?c=24355 <https://edas.info/newPaper.php?c=24355>Special Track: GPU - Accelerator Virtualization Call for PapersVirtualization technologies constitute a key enabling factor for flexible resource managementin modern data centers, and particularly in cloud environments. Cloud providers need tomanage complex infrastructures in a seamless fashion to support the highly dynamic andheterogeneous workloads and hosted applications customers deploy. Similarly, HPCenvironments have been increasingly adopting techniques that enable flexible managementof vast computing and networking resources, close to marginal provisioning cost, which isunprecedented in the history of scientific and commercial computing.Various virtualization technologies contribute to the overall picture in different ways: machinevirtualization, with its capability to enable consolidation of multiple underutilized servers withheterogeneous software and operating systems (OSes), and its capability to live-migrate afully operating virtual machine (VM) with a very short downtime, enables novel and dynamicways to manage physical servers; OS-level virtualization (i.e., containerization), with itscapability to isolate multiple user-space environments and to allow for their coexistencewithin the same OS kernel, promises to provide many of the advantages of machine virtualization with high levels of responsiveness and performance; I/O Virtualization allows physical network interfaces to take traffic from multiple VMs or containers; network virtualization, with its capability to create logical network overlays that are independent of theunderlying physical topology is furthermore enabling virtualization of HPC infrastructures. PublicationAccepted papers will be published in a Springer LNCS proceedings volume.Topics of InterestThe VHPC program committee solicits original, high-quality submissions related tovirtualization across the entire software stack with a special focus on the intersection of HPCand the cloud.Major Topics- Virtualization in supercomputing environments, HPC clusters, HPC in the cloud and grids- OS-level virtualization and containers (LXC, Docker, rkt, Singularity, Shifter, i.a.)- Lightweight/specialized operating systems in conjunction with virtual machines- Novel unikernels and use cases for virtualized HPC environments- Performance improvements for or driven by unikernels- Tool support for unikernels: configuration/build environments, debuggers, profilers- Hypervisor extensions to mitigate side-channel attacks ([micro-]architectural timing attacks, privilege escalation)- VM & Container trust and security- Containers inside VMs with hypervisor isolation- GPU virtualization operationalization- Approaches to GPGPU virtualization including API remoting and hypervisor abstraction- Optimizations of virtual machine monitor platforms and hypervisors- Hypervisor support for heterogeneous resources (GPUs, co-processors, FPGAs, etc.)- Virtualization support for emerging memory technologies- Virtualization in enterprise HPC and microvisors- Software defined networks and network virtualization- Management, deployment of virtualized environments and orchestration (Kubernetes i.a.)- Workflow-pipeline container-based composability - Checkpointing facilitation utilizing containers and VMs - Emerging topics including multi-kernel approaches and NUMA in hypervisors- Operating MPI in containers/VMs and Unikernels - Virtualization in data intensive computing (big data) - HPC convergence- Adaptation of HPC technologies in the cloud (high performance networks, RDMA, etc.)- Performance measurement, modelling and monitoring of virtualized/cloud workloads- Latency-and jitter sensitive workloads in virtualized/containerized environments- I/O virtualization (including applications, SR-IOV, i.a.) - Hybrid local facility + cloud compute and based storage systems, cloudbursting- FPGA and many-core accelerator virtualization- Job scheduling/control/policy and container placement in virtualized environments- Cloud reliability, fault-tolerance and high-availability- QoS and SLA in virtualized environments- IaaS platforms, cloud frameworks and APIs- Energy-efficient and power-aware virtualization- Configuration management tools for containers (including in OpenStack, Ansible, i.a.)- ARM-based hypervisors, ARM virtualization extensionsSpecial Track: GPU - Accelerator VirtualizationGPU virtualization technologies, performance and benchmarking, integration withworkflow scheduling systems, integration to cluster managers.GPUs are taking on many HPC workload areas, especially in deep learning withinmachine learning. In addition, a lot of workload is being pushed to elastic environments utilizing various virtualization technologies on different levels like hypervisors (e.g. VMWare, Xen, KVM), kernel (Docker, Kubernetes) or on the resource managerlevel (YARN, Mesos). In this track we invite submissions addressing these problems. Suggested Themes and Topics:Technology - What technologies and best practices exist for GPU - hardware accelerator virtualization and usage of hardware accelerators in virtual environments on the hypervisor, kernel or resource manager levelDevelopers - Real-life experience when addressing HPC/ML/DL problems with GPUs or hardware accelerators in virtual environmentsPerformance - Performance comparisons between different technologies / solutionsThe Workshop on Virtualization in High-Performance Cloud Computing (VHPC) aims tobring together researchers and industrial practitioners facing the challenges posed by virtualization in order to foster discussion, collaboration, mutual exchangeof knowledge and experience, enabling research to ultimately provide novelsolutions for virtualized computing systems of tomorrow.The workshop will be one day in length, composed of 20 min paper presentations, eachfollowed by 10 min discussion sections, plus lightning talks that are limited to 5 minutes.Presentations may be accompanied by interactive demonstrations.Important DatesFebruary 23, 2018 (AoE) - Abstract SubmissionApril 23, 2018 (AoE) - Paper submission deadline (Springer LNCS)May 30, 2018 - Acceptance notification June 28, 2018 - Workshop DayJuly 12, 2018 - Camera-ready version dueChairMichael Alexander (chair), Institute of Science and Technology, AustriaAnastassios Nanos (co-chair), OnApp, UKRomeo Kienzler (co-chair), IBM, SwitzerlandProgram committeeStergios Anastasiadis, University of Ioannina, Greece Jakob Blomer, CERN, Europe Eduardo César, Universidad Autonoma de Barcelona, SpainStephen Crago, USC ISI, USATommaso Cucinotta, St. Anna School of Advanced Studies, ItalyChristoffer Dall, Columbia University, USAFrançois Diakhaté, CEA, FrancePatrick Dreher, MIT, USA Kyle Hale, Northwestern University, USA Brian Kocoloski, University of Pittsburgh, USAUday Kurkure, VMware, USAJohn Lange, University of Pittsburgh, USAGiuseppe Lettieri, University of Pisa, ItalyQing Liu, Oak Ridge National Laboratory, USANikos Parlavantzas, IRISA, FranceKevin Pedretti, Sandia National Laboratories, USAAmer Qouneh, Western New England University, USA Carlos Reaño, Technical University of Valencia, SpainBorja Sotomayor, University of Chicago, USA Anata Tiwari, San Diego Supercomputer Center, USAKurt Tutschku, Blekinge Institute of Technology, Sweden Yasuhiro Watashiba, Osaka University, JapanChao-Tung Yang, Tunghai University, Taiwan Andrew Younge, Sandia National Laboratory, USANa Zhang, VMware, USAPaper Submission-PublicationPapers submitted to the workshop will be reviewed by at least twomembers of the program committee and external reviewers. Submissionsshould include abstract, keywords, the e-mail address of thecorresponding author, and must not exceed 10 pages, including tablesand figures at a main font size no smaller than 11 point. Submissionof a paper should be regarded as a commitment that, should the paperbe accepted, at least one of the authors will register and attend theconference to present the work. Accepted papers will be published in aSpringer LNCS volume. . The format must be according to the Springer LNCS Style. Initialsubmissions are in PDF; authors of accepted papers will be requestedto provide source files.Format Guidelines:ftp://ftp.springer.de/pub/tex/latex/llncs/latex2e/llncs2e.zip <ftp://ftp.springer.de/pub/tex/latex/llncs/latex2e/llncs2e.zip>Abstract, Paper Submission Link:https://edas.info/newPaper.php?c=24355 <https://edas.info/newPaper.php?c=24355>Lightning Talks Lightning Talks are non-paper track, synoptical in nature and are strictly limited to 5 minutes.They can be used to gain early feedback on ongoing research, for demonstrations, to present research results, early research ideas, perspectives and positions of interest to the community. Submit abstract via the main submission link. General InformationThe workshop is one day in length and will be held in conjunction with the InternationalSupercomputing Conference - High Performance (ISC) 2018, June 18-22, Frankfurt, Germany.*

1 0

[libvirt] [PATCH v4 00/12] Implement query-dump command
by John Ferlan 02 Feb '18

02 Feb '18

v3: https://www.redhat.com/archives/libvir-list/2018-January/msg01047.html Changes since v3: * Reorder patches, moved the "setup" patches to the first few patches and the meat-n-potatoes starting at patch 4 which is "new"-ish having been extracted from other patches to set up the buffers that the event will need. * Rather than allocating a dump buffer, use the stack variables and the jobinfo stats buffer. "Force tested" the failure to parse the stats error just to be sure it got propagated. John Ferlan (12): qemu: Introduce qemuDomainGetJobInfoMigrationStats qemu: Convert jobInfo stats into a union qemu: Introduce QEMU_DOMAIN_JOB_STATS_TYPE_SAVEDUMP qemu: Introduce QEMU_DOMAIN_JOB_STATS_TYPE_MEMDUMP qemu: Add support for DUMP_COMPLETED event qemu: Introduce qemuProcessHandleDumpCompleted qemu: Introduce qemuMonitor[JSON]QueryDump qemu: Introduce qemuDomainGetJobInfoDumpStats qemu: Add dump completed event to the capabilities qemu: Add new parameter to qemuMonitorDumpToFd qemu: Allow showing the dump progress for memory only dump docs: Add news article for query memory-only dump processing percentage docs/news.xml | 11 ++ src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_domain.c | 127 ++++++++++++-- src/qemu/qemu_domain.h | 17 +- src/qemu/qemu_driver.c | 183 ++++++++++++++++++--- src/qemu/qemu_migration.c | 13 +- src/qemu/qemu_migration_cookie.c | 4 +- src/qemu/qemu_monitor.c | 38 ++++- src/qemu/qemu_monitor.h | 37 ++++- src/qemu/qemu_monitor_json.c | 103 +++++++++++- src/qemu/qemu_monitor_json.h | 6 +- src/qemu/qemu_process.c | 42 ++++- .../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 + .../caps_2.6.0-gicv2.aarch64.xml | 1 + .../caps_2.6.0-gicv3.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.7.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.8.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 1 + tests/qemumonitorjsontest.c | 3 +- 30 files changed, 548 insertions(+), 55 deletions(-) -- 2.13.6

2 26

[libvirt] [PATCH] util: Remove unnecessary initialization
by John Ferlan 02 Feb '18

02 Feb '18

VIR_ALLOC will already initialize, so no need to do it again. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- This is something Coverity noted a while ago that I found sitting in one of my branches that I'd forgotten about. Pushed as trivial. src/util/virsysinfo.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/util/virsysinfo.c b/src/util/virsysinfo.c index 855580d44..e8d337191 100644 --- a/src/util/virsysinfo.c +++ b/src/util/virsysinfo.c @@ -597,8 +597,6 @@ virSysinfoReadS390(void) goto no_memory; } - ret->nprocessor = 0; - ret->processor = NULL; if (virSysinfoParseS390Processor(outbuf, ret) < 0) goto no_memory; -- 2.13.6

1 0

[libvirt] [PATCH] qemu: Refresh capabilities when creating resctrl allocation
by Martin Kletzander 02 Feb '18

02 Feb '18

Since one of the things in capabilities (info from resctrl updated with data about caches) can be change on the system by remounting the /sys/fs/resctrl with different options, the capabilities need to be refreshed. There is a better fix in the works, but it's going to be way bigger than this (hence the XXX note there), so for the time being let's workaround this. And in order not to slow down the domain starting, only get the capabilities if there are any cachetunes. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1540780 Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- src/qemu/qemu_process.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index bcd4ac8ad699..6cdb9ebc7fce 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -2514,9 +2514,15 @@ qemuProcessResctrlCreate(virQEMUDriverPtr driver, { int ret = -1; size_t i = 0; - virCapsPtr caps = virQEMUDriverGetCapabilities(driver, false); + virCapsPtr caps = NULL; qemuDomainObjPrivatePtr priv = vm->privateData; + if (!vm->def->ncachetunes) + return 0; + + /* Force capability refresh since resctrl info can change + * XXX: move cache info into virresctrl so caps are not needed */ + caps = virQEMUDriverGetCapabilities(driver, true); if (!caps) return -1; -- 2.16.1

2 3

[libvirt] [PATCH 0/3] Misc util/ fixes plus tests
by Martin Kletzander 02 Feb '18

02 Feb '18

Yay!!! \o/ Patches! Martin Kletzander (3): util: Fix possible leak in virResctrlAllocMasksAssign util: Clear unused part of the map in virBitmapShrink tests: Add test for properly removing cachetune entries src/util/virbitmap.c | 13 +++++++++ src/util/virresctrl.c | 4 +-- .../genericxml2xmlindata/cachetune-extra-tunes.xml | 33 ++++++++++++++++++++++ .../cachetune-extra-tunes.xml | 30 ++++++++++++++++++++ tests/genericxml2xmltest.c | 1 + tests/virbitmaptest.c | 5 ++++ 6 files changed, 84 insertions(+), 2 deletions(-) create mode 100644 tests/genericxml2xmlindata/cachetune-extra-tunes.xml create mode 100644 tests/genericxml2xmloutdata/cachetune-extra-tunes.xml -- 2.16.1

2 14

[libvirt] [PATCH v2 00/15] Misc build refactoring / isolation work
by Daniel P. Berrangé 02 Feb '18

02 Feb '18

This was triggered by the recent Fedora change to add '-z defs' to RPM builds by default which breaks libvirt. Various make rule changes can fix much of the problem, but it also requires source refactoring to get rid of places where virt drivers directly call into the storage/network drivers. Co-incidentally this work will also be useful in allowing us to separate out drivers to distinct daemons. In v2: - Fixed header file name comment - Resolve conflicts - Fix unit tests - Fix bisectable build by moving libvirt_lxc build patch earlier - Update syntax check header include rule Daniel P. Berrangé (15): storage: extract storage file backend from main storage driver backend storage: move storage file backend framework into util directory rpc: don't link in second copy of RPC code to libvirtd & lockd plugin build: link libvirt_lxc against libvirt.so conf: introduce callback registration for domain net device allocation conf: expand network device callbacks to cover bandwidth updates qemu: replace networkGetNetworkAddress with public API calls conf: expand network device callbacks to cover resolving NIC type network: remove conditional declarations conf: move virStorageTranslateDiskSourcePool into domain conf storage: export virStoragePoolLookupByTargetPath as a public API build: explicitly link all modules with libvirt.so build: provide a AM_FLAGS_MOD for loadable modules build: passing the "-z defs" linker flag to prevent undefined symbols cfg: forbid includes of headers in network and storage drivers again cfg.mk | 2 +- configure.ac | 1 + daemon/Makefile.am | 3 +- include/libvirt/libvirt-storage.h | 2 + m4/virt-linker-no-undefined.m4 | 32 ++ po/POTFILES.in | 2 +- src/Makefile.am | 142 ++++---- src/bhyve/bhyve_command.c | 7 +- src/conf/domain_conf.c | 355 +++++++++++++++++++ src/conf/domain_conf.h | 71 ++++ src/driver-storage.h | 5 + src/libvirt-storage.c | 40 +++ src/libvirt_private.syms | 29 ++ src/libvirt_public.syms | 6 + src/libvirt_remote.syms | 11 +- src/libxl/libxl_domain.c | 5 +- src/libxl/libxl_driver.c | 7 +- src/lxc/lxc_driver.c | 5 +- src/lxc/lxc_process.c | 7 +- src/network/bridge_driver.c | 144 ++------ src/network/bridge_driver.h | 72 ---- src/qemu/qemu_alias.c | 3 +- src/qemu/qemu_command.c | 1 - src/qemu/qemu_domain.c | 3 - src/qemu/qemu_domain_address.c | 3 +- src/qemu/qemu_driver.c | 15 +- src/qemu/qemu_hotplug.c | 18 +- src/qemu/qemu_migration.c | 3 +- src/qemu/qemu_process.c | 115 +++++- src/remote/remote_driver.c | 1 + src/remote/remote_protocol.x | 17 +- src/remote_protocol-structs | 7 + src/security/virt-aa-helper.c | 2 - src/storage/storage_backend.c | 66 ---- src/storage/storage_backend.h | 75 ---- src/storage/storage_backend_fs.c | 8 +- src/storage/storage_backend_gluster.c | 4 +- src/storage/storage_driver.c | 256 +------------- src/storage/storage_driver.h | 3 - src/storage/storage_source.c | 645 ---------------------------------- src/storage/storage_source.h | 59 ---- src/util/virstoragefile.c | 609 +++++++++++++++++++++++++++++++- src/util/virstoragefile.h | 32 ++ src/util/virstoragefilebackend.c | 108 ++++++ src/util/virstoragefilebackend.h | 104 ++++++ src/vz/vz_sdk.c | 1 - tests/Makefile.am | 4 +- tests/qemuxml2argvtest.c | 4 + tests/virstoragetest.c | 1 - tools/Makefile.am | 1 + 50 files changed, 1675 insertions(+), 1441 deletions(-) create mode 100644 m4/virt-linker-no-undefined.m4 delete mode 100644 src/storage/storage_source.c delete mode 100644 src/storage/storage_source.h create mode 100644 src/util/virstoragefilebackend.c create mode 100644 src/util/virstoragefilebackend.h -- 2.14.3

2 17

[libvirt] [PATCH] qemuDomainRemoveMemoryDevice: unlink() memory backing file
by Michal Privoznik 02 Feb '18

02 Feb '18

https://bugzilla.redhat.com/show_bug.cgi?id=1461214 Since fec8f9c49af we try to use predictable file names for 'memory-backend-file' objects. But that made us provide full path to qemu when hot plugging the object while previously we provided merely a directory. But this makes qemu behave differently. If qemu sees a path terminated with a directory it calls mkstemp() and unlinks the file immediately. But if it sees full path it just calls open(path, O_CREAT ..); and never unlinks the file. Therefore it's up to libvirt to unlink the file and not leave it behind. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Zack, can you please check if this patch is suitable for your use cases? src/qemu/qemu_hotplug.c | 3 +++ src/qemu/qemu_process.c | 26 ++++++++++++++++++++++++++ src/qemu/qemu_process.h | 4 ++++ 3 files changed, 33 insertions(+) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 6dc16a105..f26e2ca60 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -3894,6 +3894,9 @@ qemuDomainRemoveMemoryDevice(virQEMUDriverPtr driver, if (qemuDomainNamespaceTeardownMemory(vm, mem) < 0) VIR_WARN("Unable to remove memory device from /dev"); + if (qemuProcessDestroyMemoryBackingPath(driver, vm, mem) < 0) + VIR_WARN("Unable to destroy memory backing path"); + virDomainMemoryDefFree(mem); /* fix the balloon size */ diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 1a0923af3..73624eefe 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -3467,6 +3467,32 @@ qemuProcessBuildDestroyMemoryPaths(virQEMUDriverPtr driver, } +int +qemuProcessDestroyMemoryBackingPath(virQEMUDriverPtr driver, + virDomainObjPtr vm, + virDomainMemoryDefPtr mem) +{ + virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver); + char *path = NULL; + int ret = -1; + + if (qemuGetMemoryBackingPath(vm->def, cfg, mem->info.alias, &path) < 0) + goto cleanup; + + if (unlink(path) < 0 && + errno != ENOENT) { + virReportSystemError(errno, _("Unable to remove %s"), path); + goto cleanup; + } + + ret = 0; + cleanup: + VIR_FREE(path); + virObjectUnref(cfg); + return ret; +} + + static int qemuProcessVNCAllocatePorts(virQEMUDriverPtr driver, virDomainGraphicsDefPtr graphics, diff --git a/src/qemu/qemu_process.h b/src/qemu/qemu_process.h index cd9a72031..3fc7d6c85 100644 --- a/src/qemu/qemu_process.h +++ b/src/qemu/qemu_process.h @@ -43,6 +43,10 @@ int qemuProcessBuildDestroyMemoryPaths(virQEMUDriverPtr driver, virDomainMemoryDefPtr mem, bool build); +int qemuProcessDestroyMemoryBackingPath(virQEMUDriverPtr driver, + virDomainObjPtr vm, + virDomainMemoryDefPtr mem); + void qemuProcessAutostartAll(virQEMUDriverPtr driver); void qemuProcessReconnectAll(virConnectPtr conn, virQEMUDriverPtr driver); -- 2.13.6

5 8

[libvirt] [PATCH] qemu: migration: Refresh device information after transferring state
by Peter Krempa 02 Feb '18

02 Feb '18

In my first approach in 4b480d10768c I overlooked the comment in qemuMigrationRunIncoming stating that during actual migration the qemuMigrationRunIncoming does not wait until the migration is complete but rather offloads that to the Finish phase of migration. This means that during actual migration qemuProcessRefreshState was called prior to qemu actually transferring the full state and thus the queries did not get the correct information. The approach worked only for restore, where we wait for the migration to finish during qemu startup. Fix the issue by calling qemuProcessRefreshState both from qemuProcessStart if there's no incomming migration and from qemuMigrationFinish so that the code actually works as expected. --- src/qemu/qemu_migration.c | 9 +++++++++ src/qemu/qemu_process.c | 17 ++++++++++------- src/qemu/qemu_process.h | 4 ++++ 3 files changed, 23 insertions(+), 7 deletions(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 1854900c9a..ea8b275601 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -5373,6 +5373,15 @@ qemuMigrationFinish(virQEMUDriverPtr driver, goto endjob; } + /* Now that the state data was transferred we can refresh the actual state + * of the devices */ + if (qemuProcessRefreshState(driver, vm, QEMU_ASYNC_JOB_MIGRATION_IN) < 0) { + /* Similarly to the case above v2 protocol will not be able to recover + * from this. Let's ignore this and perhaps stuff will not break. */ + if (v3proto) + goto endjob; + } + if (priv->job.current->status == QEMU_DOMAIN_JOB_STATUS_POSTCOPY) inPostCopy = true; diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index bcd4ac8ad6..fe12d94d37 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -6084,7 +6084,7 @@ qemuProcessLaunch(virConnectPtr conn, * function is called after a deferred migration finishes so that we can update * state influenced by the migration stream. */ -static int +int qemuProcessRefreshState(virQEMUDriverPtr driver, virDomainObjPtr vm, qemuDomainAsyncJob asyncJob) @@ -6125,9 +6125,6 @@ qemuProcessFinishStartup(virConnectPtr conn, virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver); int ret = -1; - if (qemuProcessRefreshState(driver, vm, asyncJob) < 0) - goto cleanup; - if (startCPUs) { VIR_DEBUG("Starting domain CPUs"); if (qemuProcessStartCPUs(driver, vm, conn, @@ -6231,11 +6228,17 @@ qemuProcessStart(virConnectPtr conn, VIR_DOMAIN_PAUSED_USER) < 0) goto stop; - /* Keep watching qemu log for errors during incoming migration, otherwise - * unset reporting errors from qemu log. */ - if (!incoming) + if (!incoming) { + /* Keep watching qemu log for errors during incoming migration, otherwise + * unset reporting errors from qemu log. */ qemuMonitorSetDomainLog(priv->mon, NULL, NULL, NULL); + /* Refresh state of devices from qemu. During migration this needs to + * happen after the state information is fully transferred. */ + if (qemuProcessRefreshState(driver, vm, asyncJob) < 0) + goto stop; + } + ret = 0; cleanup: diff --git a/src/qemu/qemu_process.h b/src/qemu/qemu_process.h index cd9a720313..b383ff309b 100644 --- a/src/qemu/qemu_process.h +++ b/src/qemu/qemu_process.h @@ -129,6 +129,10 @@ int qemuProcessFinishStartup(virConnectPtr conn, bool startCPUs, virDomainPausedReason pausedReason); +int qemuProcessRefreshState(virQEMUDriverPtr driver, + virDomainObjPtr vm, + qemuDomainAsyncJob asyncJob); + typedef enum { VIR_QEMU_PROCESS_STOP_MIGRATED = 1 << 0, VIR_QEMU_PROCESS_STOP_NO_RELABEL = 1 << 1, -- 2.15.0

2 1