April 2018 - Devel - libvirt List Archives

[libvirt] [dbus PATCH v2 0/8] Properties/Methods for Connect Interface
by Katerina Koukiou 09 Apr '18

09 Apr '18

Plus some minor fixes. Changes from v1: * Cabalitities property rewritten as method as dnb suggested. * Added documentation on Secure and Encrypted properties as discussed. Katerina Koukiou (8): Implement GetCapabilities method for connect Interface Implement Hostname property for Connect Interface Implement LibVersion property for Connect Interface Implement Encrypted property for Connect Interface Implement Secure property for Connect Interface Implement GetSysinfo method for connect Interface All functions in src/connect.c should have virtDBusConnect prefix Removing G_GNUC_UNUSED in cases where the parameter is used data/org.libvirt.Connect.xml | 29 ++++++ src/connect.c | 209 ++++++++++++++++++++++++++++++++++--------- src/domain.c | 10 +-- test/test_connect.py | 11 +++ 4 files changed, 214 insertions(+), 45 deletions(-) -- 2.15.0

2 11

[libvirt] [dbus PATCH 0/8] Properties/Methods for Connect Interface
by Katerina Koukiou 09 Apr '18

09 Apr '18

Plus some minor fixes. Katerina Koukiou (8): Implement Capabilities property for connect Interface Implement Hostname property for Connect Interface Implement LibVersion property for Connect Interface Implement Encrypted property for Connect Interface Implement Secure property for Connect Interface Implement GetSysinfo method for connect Interface All functions in src/connect.c should have virtDBusConnect prefix. Removing G_GNUC_UNUSED in cases where the parameter is used data/org.libvirt.Connect.xml | 26 ++++++ src/connect.c | 206 ++++++++++++++++++++++++++++++++++--------- src/domain.c | 10 +-- test/test_connect.py | 9 ++ 4 files changed, 206 insertions(+), 45 deletions(-) -- 2.15.0

3 19

[libvirt] Permissions and ownership on /dev/kvm keep reverting after starting a vm
by Tom 09 Apr '18

09 Apr '18

Hey guys, /dev/kvm permissions and ownership keeps reverting after starting a vm. The ownership and permissions keep going back to crw-rw—— root root .... After starting a vm. I have to revert the perms and ownership to: crw-crw-crw root kvm .... To start any vm but it goes back to the first set of permissions as soon as I start another vm. Any hints what I could check? Cheers, Tom Sent from my iPhone

3 2

[libvirt] [PATCH 0/2] Change virCloseCallback typedef to return void
by John Ferlan 09 Apr '18

09 Apr '18

Slightly related to some current work to clean up the Add/Remove domain object list processing - as it turns out the close callbacks run code didn't even pay attention to what was returned and it really didn't need to - so let's just call it what it is a void function and let the virCloseCallbacksRun code handle the object manipulation (lock/ref and unlock/unref). John Ferlan (2): qemu: Fix qemuProcessAutoDestroy util: Alter virCloseCallback typedef to return void src/bhyve/bhyve_process.c | 8 ++------ src/lxc/lxc_process.c | 8 ++------ src/qemu/qemu_migration.c | 7 ++----- src/qemu/qemu_process.c | 10 ++-------- src/util/virclosecallbacks.c | 5 ++--- src/util/virclosecallbacks.h | 6 +++--- 6 files changed, 13 insertions(+), 31 deletions(-) -- 2.13.6

2 5

[libvirt] [PATCH 00/11] qemu: Implement pcie-to-pci-bridge controller
by Andrea Bolognani 09 Apr '18

09 Apr '18

Patches 1-4 are cleanups and preparation. For more information, take a peek at patch 8's commit message, which also includes a link to the relevant Bugzilla entry. Andrea Bolognani (11): docs: Tweak PCI controller model documentation tests: Add aarch64-traditional-pci test conf: Remove dubious code from virDomainPCIAddressSetGrow() conf: Rename virDomainPCIAddressSet.areMultipleRootsSupported qemu: Add QEMU_CAPS_DEVICE_PCIE_PCI_BRIDGE qemu: Implement pcie-to-pci-bridge controller conf: Add virDomainPCIAddressSet.isPCIeToPCIBridgeSupported conf: Prefer pcie-to-pci-bridge to dmi-to-pci-bridge tests: Use pcie-to-pci-bridge for aarch64-traditional-pci news: Add 4.3.0 release news: Update for pcie-to-pci-bridge support docs/formatdomain.html.in | 21 ++--- docs/news.xml | 17 ++++ docs/schemas/domaincommon.rng | 3 + src/conf/domain_addr.c | 95 ++++++++++++++++------ src/conf/domain_addr.h | 8 +- src/conf/domain_conf.c | 3 + src/conf/domain_conf.h | 2 + src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 1 + src/qemu/qemu_domain.c | 17 ++++ src/qemu/qemu_domain_address.c | 14 +++- tests/qemucapabilitiesdata/caps_2.12.0.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml | 1 + .../qemuxml2argvdata/aarch64-traditional-pci.args | 27 ++++++ tests/qemuxml2argvdata/aarch64-traditional-pci.xml | 19 +++++ tests/qemuxml2argvtest.c | 9 ++ .../qemuxml2xmloutdata/aarch64-traditional-pci.xml | 43 ++++++++++ tests/qemuxml2xmltest.c | 9 ++ 19 files changed, 251 insertions(+), 42 deletions(-) create mode 100644 tests/qemuxml2argvdata/aarch64-traditional-pci.args create mode 100644 tests/qemuxml2argvdata/aarch64-traditional-pci.xml create mode 100644 tests/qemuxml2xmloutdata/aarch64-traditional-pci.xml -- 2.14.3

3 34

[libvirt] [PATCH 0/4] Introduce wildcard to log filters
by Erik Skultety 09 Apr '18

09 Apr '18

First, 2 tiny fixes along the way, then the actual change, which lets you do the following for example during runtime: virt-admin daemon-log-filters "1:* 4:remote 4:json" which previously, given the default config setting log_level=3, translated into virt-admin daemon-log-filters \ "1:access 1:admin 1:conf 1:cpu 1:qemu 1:interface 1:<etc-it's-long>" ...of course, "3:*" is equivalent to "log_level=3". Erik Skultety (4): virlog: Fix a typo in virLogParseFilter's error msg libvirtd.conf: Document that we do a 'first' match on log filters util: virlog: Introduce wildcard to log filters news: Update the news file with the log filter wildcard improvement docs/news.xml | 12 ++++++++++++ src/remote/libvirtd.conf | 6 +++++- src/util/virlog.c | 46 ++++++++++++++++++++++++++++++++++++++++++++-- src/util/virlog.h | 1 + 4 files changed, 62 insertions(+), 3 deletions(-) -- 2.14.3

2 10

[libvirt] Project for profiles and defaults for libvirt domains
by Martin Kletzander 08 Apr '18

08 Apr '18

Hi everyone! First of all sorry for such wide distribution, but apparently that's the best way to make sure we cooperate nicely. So please be considerate as this is a cross-post between huge amount of mailing lists. After some discussions with developers from different projects that work with libvirt one cannot but notice some common patterns and workarounds. So I set off to see how can we make all our lives better and our coding more effective (and maybe more fun as well). If all goes well we will create a project that will accommodate most of the defaulting, policies, workarounds and other common algorithms around libvirt domain definitions. And since early design gets you half way, I would like to know your feedback on several key points as well as on the general idea. Also correct me brutally in case I'm wrong. In order to not get confused in the following descriptions, I will refer to this project idea using the name `virtuned`, but there is really no name for it yet (although an abbreviation for "Virtualization Abstraction Definition and Hypervisor Delegation" would suit well, IMHO). Here are some common problems and use cases that virtuned could solve (or help with). Don't take it as something that's impossible to solve on your own, but rather something that could be de-duplicated from multiple projects or "done right" instead of various hack-ish solutions. 1) Default devices/values Libvirt itself must default to whatever values there were before any particular element was introduced due to the fact that it strives to keep the guest ABI stable. That means, for example, that it can't just add -vmcoreinfo option (for KASLR support) or magically add the pvpanic device to all QEMU machines, even though it would be useful, as that would change the guest ABI. For default values this is even more obvious. Let's say someone figures out some "pretty good" default values for various HyperV enlightenment feature tunables. Libvirt can't magically change them, but each one of the projects building on top of it doesn't want to keep that list updated and take care of setting them in every new XML. Some projects don't even expose those to the end user as a knob, while others might. One more thing could be automatically figuring out best values based on libosinfo-provided data. 2) Policies Lot of the time there are parts of the domain definition that need to be added, but nobody really cares about them. Sometimes it's enough to have few templates, another time you might want to have a policy per-scenario and want to combine them in various ways. For example with the data provided by point 1). For example if you want PCI-Express, you need the q35 machine type, but you don't really want to care about the machine type. Or you want to use SPICE, but you don't want to care about adding QXL. What if some of these policies could be specified once (using some DSL for example), and used by virtuned to merge them in a unified and predictable way? 3) Abstracting the XML This is probably just usable for stateless apps, but it might happen that some apps don't really want to care about the XML at all. They just want an abstract view of the domain, possibly add/remove a device and that's it. We could do that as well. I can't really tell how much of a demand there is for it, though. 4) Identifying devices properly In contrast to the previous point, stateful apps might have a problem identifying devices after hotplug. For example, let's say you don't care about the addresses and leave that up to libvirt. You hotplug a device into the domain and dump the new XML of it. Depending on what type of device it was, you might need to identify it based on different values. It could be <target dev=''/> for disks, <mac address=''/> for interfaces etc. For some devices it might not even be possible and you need to remember the addresses of all the previous devices and then parse them just to identify that one device and then throw them away. With new enough libvirt you could use the user aliases for that, but turns out it's not that easy to use them properly anyway. Also the aliases won't help users identify that device inside the guest. <rant> We really should've gone with new attribute for the user alias instead of using an existing one, given how many problems that is causing. </rant> 5) Generating the right XML snippet for device hot-(un)plug This is kind of related to some previous points. When hot-plugging a device and creating an XML snippet for it, you want to keep the defaults from point 1) and policies from 2) in mind. Or something related to the already existing domain which you can describe systematically. And adding something for identification (see previous point). Doing the hot-unplug is easy depending on how much information about that device is saved by your application. The less you save about the device (or show to the user in a GUI, if applicable) the harder it might be to generate an XML that libvirt will accept. Again, some problems with this should be fixed in libvirt, some of them are easy to workaround. But having a common ground that takes care of this should help some projects. Hot-unplug could be implemented just based on the alias. This is something that would fit into libvirt as well. ======================================================================== To mention some pre-existing solutions: - I understand OpenStack has some really sensible and wisely chosen and/or tested default values. - I know KubeVirt has VirtualMachinePresets. That is something closely related to points 1) and 2). Also their abstraction of the XML might be usable for point 3). - There was an effort on creating policy based configuration of libvirt objects called libvirt-designer. This is closely related to points 2) and 3). Unfortunately there was no much going on lately and part of virt-manager repository has currently more features implemented with the same ideas in mind, just not exported for public use. We could utilize some of the above to various extents. Let me know what you think and have a nice day. Martin

6 14

[libvirt] [PATCH v2] docs: add page describing goals for host platform version support
by Daniel P. Berrangé 07 Apr '18

07 Apr '18

Described how we decide which host platforms to support for libvirt, which in turn makes it easier to decide when a platform / software version can be dropped. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- docs/index.html.in | 2 +- docs/platforms.html.in | 105 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 106 insertions(+), 1 deletion(-) create mode 100644 docs/platforms.html.in diff --git a/docs/index.html.in b/docs/index.html.in index 1b3a7a3db6..4783c39e3c 100644 --- a/docs/index.html.in +++ b/docs/index.html.in @@ -28,7 +28,7 @@ The libvirt project: </p> <ul> - <li>is a toolkit to manage virtualization hosts</li> + <li>is a toolkit to manage <a href="platforms.html.in">virtualization platforms</a></li> <li>is accessible from C, Python, Perl, Java and more</li> <li>is licensed under open source licenses</li> <li>supports <a href="drvqemu.html">KVM</a>, diff --git a/docs/platforms.html.in b/docs/platforms.html.in new file mode 100644 index 0000000000..776e930e78 --- /dev/null +++ b/docs/platforms.html.in @@ -0,0 +1,105 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE html> +<html xmlns="http://www.w3.org/1999/xhtml"> + <body> + <h1>Supported host platforms</h1> + + <ul id="toc"></ul> + + <h2>Build targets</h2> + + <p> + Libvirt drivers aim to support building and executing on multiple + host OS platforms. This document outlines which platforms are the + major build targets. These platforms are used as the basis for deciding + upon the minimum required versions of 3rd party software libvirt depends + on. If a platform is not listed here, it does not imply that libvirt + won't work. If an unlisted platform has comparable software versions + to a listed platform, there is every expectation that it will work. + Bug reports are welcome for problems encountered on unlisted platforms + unless they are clearly older vintage that what is described here. + </p> + + <p> + Note that when considering software versions shipped in distros as + support targets, libvirt considers only the version number, and assumes + the features in that distro match the upstream release with the same + version. IOW, if a distro backports extra features to the software in + their distro, libvirt upstream code will not add explicit support for + those backports, unless the feature is auto-detectable in a manner that + works for the upstream releases too. + </p> + + <p> + The Repology site is a useful resource to identify currently shipped + versions of software in various operating systems, though it does not + cover all distros listed below. + </p> + + <ul> + <li><a href="https://repology.org/metapackage/libvirt/versions">libvirt</a></li> + <li><a href="https://repology.org/metapackage/qemu/versions">qemu</a></li> + </ul> + + + <h3>Linux OS</h3> + + <p> + For distributions with frequent, short-lifetime releases, the project + will aim to support all versions that are not end of life by their + respective vendors. For the purposes of identifying supported software + versions, the project will look at Fedora, Ubuntu & OpenSUSE distros. + Other short-lifetime distros will be assumed to ship similar software + versions. + </p> + + <p> + For distributions with long-lifetime releases, the project will aim to + support the most recent major version at all times. Support for the + previous major version will be dropped 2 years after the new major + version is released. For the purposes of identifying supported software + versions, the project will look at RHEL, Debian, Ubuntu LTS & SLES + distros. Other long-lifetime distros will be assumed to ship similar + software versions. + </p> + + <h3>Windows</h3> + + <p> + The project supports building with current versions of the MinGW + toolchain, hosted on Linux. + </p> + + <h3>macOS</h3> + + <p> + The project supports building with the current version of macOS, + with the current homebrew package set available. + </p> + + <h3>FreeBSD</h3> + + <p> + The project aims to support the most recent major version + at all times. Support for the previous major version will + be dropped 2 years after the new major version is released. + </p> + + <h2>Virtualization platforms</h2> + + <p> + For <a href="drivers.html">hypervisor drivers</a> which execute + locally (QEMU, LXC, VZ, libxl, etc), the set of supported operating + system platforms listed above will inform choices as to the minimum + required versions of 3rd party libraries and hypervisor management + APIs. + </p> + <p> + If a hypervisor is not commonly shipped directly by any distro + listed above, (VMware ESX, HyperV, VZ), the project aims to + support versions up to 5 years, or until the vendor discontinues + support, whichever comes first. + </p> + + </body> +</html> -- 2.14.3

5 5

[libvirt] [PATCH 0/7] Remove the legacy xen driver
by Jim Fehlig 07 Apr '18

07 Apr '18

Long overdue first cut at remove the old xen driver. The first 3 patches move existing tests to WITH_LIBXL since we'll want to continue supporting conversion of the various xen config formats. The remain patches remove the cruft. Jim Fehlig (7): tests: move xml2sexpr tests to WITH_LIBXL tests: move sexpr2xml tests to WITH_LIBXL tests: move xmconfig tests to WITH_LIBXL Remove xencaps tests and data files Remove the xend driver docs: remove mention of legacy Xen driver spec: remove legacy xen driver configure.ac | 7 +- docs/architecture.html.in | 28 +- docs/bugs.html.in | 3 +- docs/uri.html.in | 74 - docs/windows.html.in | 2 +- libvirt.spec.in | 57 +- m4/virt-driver-xen.m4 | 142 - po/POTFILES.in | 7 - src/Makefile.am | 1 - src/xen/Makefile.inc.am | 67 - src/xen/block_stats.c | 355 --- src/xen/block_stats.h | 38 - src/xen/xen_driver.c | 2845 ----------------- src/xen/xen_driver.h | 204 -- src/xen/xen_hypervisor.c | 3125 ------------------- src/xen/xen_hypervisor.h | 142 - src/xen/xen_inotify.c | 447 --- src/xen/xen_inotify.h | 33 - src/xen/xend_internal.c | 3221 -------------------- src/xen/xend_internal.h | 213 -- src/xen/xm_internal.c | 1484 --------- src/xen/xm_internal.h | 105 - src/xen/xs_internal.c | 920 ------ src/xen/xs_internal.h | 101 - tests/Makefile.am | 59 +- tests/sexpr2xmldata/sexpr2xml-boot-grub.xml | 3 +- tests/sexpr2xmldata/sexpr2xml-bridge-ipaddr.xml | 3 +- tests/sexpr2xmldata/sexpr2xml-curmem.xml | 1 - .../sexpr2xml-disk-block-shareable.xml | 1 - tests/sexpr2xmldata/sexpr2xml-disk-block.xml | 3 +- .../sexpr2xml-disk-drv-blktap-qcow.xml | 1 - .../sexpr2xml-disk-drv-blktap-raw.xml | 1 - .../sexpr2xml-disk-drv-blktap2-raw.xml | 1 - tests/sexpr2xmldata/sexpr2xml-disk-file.xml | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-autoport.xml | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-empty-kernel.xml | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-force-hpet.xml | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-force-nohpet.xml | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-kernel.xml | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-localtime.xml | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-net-netfront.xml | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-parallel-tcp.xml | 7 +- .../sexpr2xml-fv-serial-dev-2-ports.xml | 7 +- .../sexpr2xml-fv-serial-dev-2nd-port.xml | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-file.xml | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-null.xml | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-pipe.xml | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-pty.xml | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-stdio.xml | 7 +- .../sexpr2xml-fv-serial-tcp-telnet.xml | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-tcp.xml | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-udp.xml | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-unix.xml | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-sound-all.xml | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-sound.xml | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-usbmouse.xml | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-usbtablet.xml | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-utc.xml | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-v2.xml | 7 +- tests/sexpr2xmldata/sexpr2xml-fv.xml | 7 +- tests/sexpr2xmldata/sexpr2xml-net-bridged.xml | 3 +- tests/sexpr2xmldata/sexpr2xml-net-e1000.xml | 3 +- tests/sexpr2xmldata/sexpr2xml-net-routed.xml | 3 +- tests/sexpr2xmldata/sexpr2xml-no-source-cdrom.xml | 6 +- tests/sexpr2xmldata/sexpr2xml-pci-devs.xml | 5 +- .../sexpr2xml-pv-bootloader-cmdline.xml | 3 +- tests/sexpr2xmldata/sexpr2xml-pv-bootloader.xml | 3 +- tests/sexpr2xmldata/sexpr2xml-pv-localtime.xml | 3 +- tests/sexpr2xmldata/sexpr2xml-pv-vcpus.xml | 3 +- .../sexpr2xml-pv-vfb-new-vncdisplay.xml | 3 +- tests/sexpr2xmldata/sexpr2xml-pv-vfb-new.xml | 3 +- .../sexpr2xmldata/sexpr2xml-pv-vfb-type-crash.xml | 3 +- tests/sexpr2xmldata/sexpr2xml-pv.xml | 3 +- tests/sexpr2xmldata/sexpr2xml-vif-rate.xml | 7 +- tests/sexpr2xmltest.c | 35 +- tests/testutilsxen.c | 64 - tests/testutilsxen.h | 2 - tests/vircapstest.c | 34 - tests/virdrivermoduletest.c | 3 - tests/virschematest.c | 3 +- tests/xencapsdata/xen-i686-pae-hvm.caps | 1 - tests/xencapsdata/xen-i686-pae-hvm.cpuinfo | 37 - tests/xencapsdata/xen-i686-pae-hvm.xml | 49 - tests/xencapsdata/xen-i686-pae.caps | 1 - tests/xencapsdata/xen-i686-pae.cpuinfo | 18 - tests/xencapsdata/xen-i686-pae.xml | 32 - tests/xencapsdata/xen-i686.caps | 1 - tests/xencapsdata/xen-i686.cpuinfo | 18 - tests/xencapsdata/xen-i686.xml | 29 - tests/xencapsdata/xen-ia64-be-hvm.caps | 1 - tests/xencapsdata/xen-ia64-be-hvm.cpuinfo | 29 - tests/xencapsdata/xen-ia64-be-hvm.xml | 45 - tests/xencapsdata/xen-ia64-be.caps | 1 - tests/xencapsdata/xen-ia64-be.cpuinfo | 29 - tests/xencapsdata/xen-ia64-be.xml | 29 - tests/xencapsdata/xen-ia64-hvm.caps | 1 - tests/xencapsdata/xen-ia64-hvm.cpuinfo | 29 - tests/xencapsdata/xen-ia64-hvm.xml | 41 - tests/xencapsdata/xen-ia64.caps | 1 - tests/xencapsdata/xen-ia64.cpuinfo | 29 - tests/xencapsdata/xen-ia64.xml | 26 - tests/xencapsdata/xen-ppc64.caps | 1 - tests/xencapsdata/xen-ppc64.cpuinfo | 0 tests/xencapsdata/xen-ppc64.xml | 26 - tests/xencapsdata/xen-x86_64-hvm.caps | 1 - tests/xencapsdata/xen-x86_64-hvm.cpuinfo | 47 - tests/xencapsdata/xen-x86_64-hvm.xml | 61 - tests/xencapsdata/xen-x86_64.caps | 1 - tests/xencapsdata/xen-x86_64.cpuinfo | 47 - tests/xencapsdata/xen-x86_64.xml | 29 - tests/xencapstest.c | 224 -- tests/xmconfigdata/test-disk-drv-blktap-raw.xml | 3 +- tests/xmconfigdata/test-disk-drv-blktap2-raw.xml | 3 +- tests/xmconfigdata/test-escape-paths.xml | 11 +- .../xmconfigdata/test-fullvirt-default-feature.xml | 9 +- tests/xmconfigdata/test-fullvirt-force-hpet.xml | 9 +- tests/xmconfigdata/test-fullvirt-force-nohpet.xml | 9 +- tests/xmconfigdata/test-fullvirt-localtime.xml | 9 +- tests/xmconfigdata/test-fullvirt-net-netfront.xml | 9 +- tests/xmconfigdata/test-fullvirt-new-cdrom.xml | 9 +- tests/xmconfigdata/test-fullvirt-nohap.xml | 9 +- tests/xmconfigdata/test-fullvirt-parallel-tcp.xml | 9 +- tests/xmconfigdata/test-fullvirt-serial-file.xml | 9 +- tests/xmconfigdata/test-fullvirt-serial-null.xml | 9 +- tests/xmconfigdata/test-fullvirt-serial-pipe.xml | 9 +- tests/xmconfigdata/test-fullvirt-serial-pty.xml | 9 +- tests/xmconfigdata/test-fullvirt-serial-stdio.xml | 9 +- .../test-fullvirt-serial-tcp-telnet.xml | 9 +- tests/xmconfigdata/test-fullvirt-serial-tcp.xml | 9 +- tests/xmconfigdata/test-fullvirt-serial-udp.xml | 9 +- tests/xmconfigdata/test-fullvirt-serial-unix.xml | 9 +- tests/xmconfigdata/test-fullvirt-sound.xml | 9 +- tests/xmconfigdata/test-fullvirt-usbmouse.xml | 9 +- tests/xmconfigdata/test-fullvirt-usbtablet.xml | 9 +- tests/xmconfigdata/test-fullvirt-utc.xml | 9 +- tests/xmconfigdata/test-no-source-cdrom.xml | 9 +- tests/xmconfigdata/test-paravirt-maxvcpus.xml | 5 +- tests/xmconfigdata/test-paravirt-net-e1000.xml | 5 +- tests/xmconfigdata/test-paravirt-net-vifname.xml | 5 +- .../test-paravirt-new-pvfb-vncdisplay.xml | 5 +- tests/xmconfigdata/test-paravirt-new-pvfb.xml | 5 +- tests/xmconfigdata/test-paravirt-vcpu.xml | 5 +- tests/xmconfigdata/test-pci-devs.xml | 11 +- tests/xmconfigtest.c | 22 +- tests/xml2sexprdata/xml2sexpr-escape.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-fv-force-hpet.sexpr | 2 +- .../xml2sexprdata/xml2sexpr-fv-force-nohpet.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-fv-kernel.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-fv-localtime.sexpr | 2 +- .../xml2sexprdata/xml2sexpr-fv-net-netfront.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-fv-net-rate.sexpr | 2 +- .../xml2sexprdata/xml2sexpr-fv-parallel-tcp.sexpr | 2 +- .../xml2sexpr-fv-serial-dev-2-ports.sexpr | 2 +- .../xml2sexpr-fv-serial-dev-2nd-port.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-fv-serial-file.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-fv-serial-null.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-fv-serial-pipe.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-fv-serial-pty.sexpr | 2 +- .../xml2sexprdata/xml2sexpr-fv-serial-stdio.sexpr | 2 +- .../xml2sexpr-fv-serial-tcp-telnet.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-fv-serial-tcp.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-fv-serial-udp.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-fv-serial-unix.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-fv-sound.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-fv-usbmouse.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-fv-utc.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-fv-v2.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-fv-vncunused.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-fv.sexpr | 2 +- tests/xml2sexprtest.c | 7 +- 170 files changed, 282 insertions(+), 15004 deletions(-) delete mode 100644 m4/virt-driver-xen.m4 delete mode 100644 src/xen/Makefile.inc.am delete mode 100644 src/xen/block_stats.c delete mode 100644 src/xen/block_stats.h delete mode 100644 src/xen/xen_driver.c delete mode 100644 src/xen/xen_driver.h delete mode 100644 src/xen/xen_hypervisor.c delete mode 100644 src/xen/xen_hypervisor.h delete mode 100644 src/xen/xen_inotify.c delete mode 100644 src/xen/xen_inotify.h delete mode 100644 src/xen/xend_internal.c delete mode 100644 src/xen/xend_internal.h delete mode 100644 src/xen/xm_internal.c delete mode 100644 src/xen/xm_internal.h delete mode 100644 src/xen/xs_internal.c delete mode 100644 src/xen/xs_internal.h delete mode 100644 tests/xencapsdata/xen-i686-pae-hvm.caps delete mode 100644 tests/xencapsdata/xen-i686-pae-hvm.cpuinfo delete mode 100644 tests/xencapsdata/xen-i686-pae-hvm.xml delete mode 100644 tests/xencapsdata/xen-i686-pae.caps delete mode 100644 tests/xencapsdata/xen-i686-pae.cpuinfo delete mode 100644 tests/xencapsdata/xen-i686-pae.xml delete mode 100644 tests/xencapsdata/xen-i686.caps delete mode 100644 tests/xencapsdata/xen-i686.cpuinfo delete mode 100644 tests/xencapsdata/xen-i686.xml delete mode 100644 tests/xencapsdata/xen-ia64-be-hvm.caps delete mode 100644 tests/xencapsdata/xen-ia64-be-hvm.cpuinfo delete mode 100644 tests/xencapsdata/xen-ia64-be-hvm.xml delete mode 100644 tests/xencapsdata/xen-ia64-be.caps delete mode 100644 tests/xencapsdata/xen-ia64-be.cpuinfo delete mode 100644 tests/xencapsdata/xen-ia64-be.xml delete mode 100644 tests/xencapsdata/xen-ia64-hvm.caps delete mode 100644 tests/xencapsdata/xen-ia64-hvm.cpuinfo delete mode 100644 tests/xencapsdata/xen-ia64-hvm.xml delete mode 100644 tests/xencapsdata/xen-ia64.caps delete mode 100644 tests/xencapsdata/xen-ia64.cpuinfo delete mode 100644 tests/xencapsdata/xen-ia64.xml delete mode 100644 tests/xencapsdata/xen-ppc64.caps delete mode 100644 tests/xencapsdata/xen-ppc64.cpuinfo delete mode 100644 tests/xencapsdata/xen-ppc64.xml delete mode 100644 tests/xencapsdata/xen-x86_64-hvm.caps delete mode 100644 tests/xencapsdata/xen-x86_64-hvm.cpuinfo delete mode 100644 tests/xencapsdata/xen-x86_64-hvm.xml delete mode 100644 tests/xencapsdata/xen-x86_64.caps delete mode 100644 tests/xencapsdata/xen-x86_64.cpuinfo delete mode 100644 tests/xencapsdata/xen-x86_64.xml delete mode 100644 tests/xencapstest.c -- 2.16.2

3 11

[libvirt] [PATCH 0/4] Initial phase of domain obj add/remove cleanup
by John Ferlan 07 Apr '18

07 Apr '18

As evidenced by various code comments, the process of adding and removing objects to/from the domain object list is problematic. Long story short is that the Add logic doesn't generate enough object references and the Remove logic removes one extra than was added during Add and leaves the object unlocked upon return (as well as doing a small fire dance to ensure proper lock ordering). Some drivers (libxl, lxc, qemu, and vz) handle the not enough references by adding an virObjectRef to the object returned from the Add code, while others (bhyve, openvz, test, uml, and vmware) live rather vicariously and carefully, but at least don't reference the object after calling Remove. Fixing all this will take a few patch streams across a few mostly dormant driver modules and some coordination with the vir*FindBy{UUID|ID|Name} logic. Some of that was already posted previously, but only received minimal notice: https://www.redhat.com/archives/libvir-list/2018-March/msg00489.html So rather than (re)posting a 20-30 patch series on list which probably won't get reviewed, I'll take things in smaller batches of patches in the hopes that all this can be worked through so that the end result is "cleaner" (and agreed upon). John Ferlan (4): conf: Fix error path logic in virDomainObjListAddLocked conf: Fix error path logic in virDomainObjListLoadStatus conf: Introduce virDomainObjListAddObjLocked conf: Fix virDomainObjParseFile object handling src/conf/virdomainobjlist.c | 63 ++++++++++++++++++++++++++++----------------- src/lxc/lxc_controller.c | 2 +- tests/qemuxml2xmltest.c | 2 +- 3 files changed, 42 insertions(+), 25 deletions(-) -- 2.13.6

2 10