[libvirt] [dbus PATCH v2 0/8] Properties/Methods for Connect Interface
by Katerina Koukiou
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
7 years, 2 months
[libvirt] [dbus PATCH 0/8] Properties/Methods for Connect Interface
by Katerina Koukiou
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
7 years, 2 months
[libvirt] Permissions and ownership on /dev/kvm keep reverting after starting a vm
by Tom
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
7 years, 2 months
[libvirt] [PATCH 0/2] Change virCloseCallback typedef to return void
by John Ferlan
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
7 years, 2 months
[libvirt] [PATCH 00/11] qemu: Implement pcie-to-pci-bridge controller
by Andrea Bolognani
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
7 years, 2 months
[libvirt] [PATCH 0/4] Introduce wildcard to log filters
by Erik Skultety
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
7 years, 2 months
[libvirt] Project for profiles and defaults for libvirt domains
by Martin Kletzander
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
7 years, 2 months
[libvirt] [PATCH v2] docs: add page describing goals for host platform version support
by Daniel P. Berrangé
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
7 years, 2 months
[libvirt] [PATCH 0/7] Remove the legacy xen driver
by Jim Fehlig
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
7 years, 2 months
[libvirt] [PATCH 0/4] Initial phase of domain obj add/remove cleanup
by John Ferlan
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
7 years, 2 months
