Current implementation does not detect all incompatible configurations.
For example if we have in vzsdk bootorder "cdrom1, cdrom0" (that is
"hdb, hda" in case of ide cdroms) and cdroms do not have disk
images inserted. In this case boot order check code fails to
distiguish them at all as for both PrlVmDev_GetFriendlyName gives "".
Well the consequences are only missing warnings but as
we just have introduced all the necessary tools to face the problem -
let's fix it.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Actually using disk PrlVmDev_GetFriendlyName as id on
detaching volumes is not a problem. We can only detach
hard disks and these can not have empty friendly names.
But upcoming update device functionality for cdroms
can not use disk source as id at all as update operation
typically change this same source value. Thus we will need
to use cdrom bus and cdrom target name as cdrom id. So in attempt
to use same id scheme for all purpuses lets fix hard disk
detach function to use new id.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Our intention is to use disk bus and disk target name pair
as disk id instead of name returned by PrlVmDev_GetFriendlyName.
We already have the code that extracts this pair from vzsdk
data. Let's factor it out into a function.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Laine Stump [Mon, 18 Apr 2016 18:18:37 +0000 (14:18 -0400)]
test: enable testing for expected parse errors in network XML
This is patterned after similar functionality for domain XML tests,
but tries harder to avoid reading non-existent networkxml2xmlout data
file when parse fails.
So in glibc-2.23 sys/sysmacros.h is no longer included from sys/types.h
and we don't build because of the usage of major/minor/makedev macros.
Autoconf already has AC_HEADER_MAJOR macro that check where exactly
these functions/macros are defined, so let's use that.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
John Ferlan [Sat, 16 Apr 2016 12:11:00 +0000 (08:11 -0400)]
tests: Fix syntax in iSCSI auth/secret tests
While working on the tests for the secret initialization vector, I found
that the existing iSCSI tests were lacking in how they defined the IQN.
Many had IQN's of just 'iqn.1992-01.com.example' for one disk while using
'iqn.1992-01.com.example/1' for the second disk (same for hostdevs - guess
how they were copied/generated).
Typically (and documented this way), IQN's would include be of the form
'iqn.1992-01.com.example:storage/1' indicating an IQN using "storage" for
naming authority specific string and "/1" for the iSCSI LUN.
So modify the input XML's to use the more proper format - this of course
has a ripple effect on the output XML and the args.
Also note that the "%3A" is generated by the virURIFormat/xmlSaveUri
to represent the colon.
Since threadpool increments the current number of threads according to current
load, i.e. how many jobs are waiting in the queue. The count however, is
constrained by max and min limits of workers. The logic of this new API works
like this:
1) setting the minimum
a) When the limit is increased, depending on the current number of
threads, new threads are possibly spawned if the current number of
threads is less than the new minimum limit
b) Decreasing the minimum limit has no possible effect on the current
number of threads
2) setting the maximum
a) Icreasing the maximum limit has no immediate effect on the current
number of threads, it only allows the threadpool to spawn more
threads when new jobs, that would otherwise end up queued, arrive.
b) Decreasing the maximum limit may affect the current number of
threads, if the current number of threads is less than the new
maximum limit. Since there may be some ongoing time-consuming jobs
that would effectively block this API from killing any threads.
Therefore, this API is asynchronous with best-effort execution,
i.e. the necessary number of workers will be terminated once they
finish their previous job, unless other workers had already
terminated, decreasing the limit to the requested value.
3) setting priority workers
- both increase and decrease in count of these workers have an
immediate impact on the current number of workers, new ones will be
spawned or some of them get terminated respectively.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
New API to retrieve current server workerpool specs. Since it uses typed
parameters, more specs to retrieve can be further included in the pool of
supported ones.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Erik Skultety [Thu, 25 Feb 2016 12:14:36 +0000 (13:14 +0100)]
util: Add more getters to threadpool parameters
In order for the client to see all thread counts and limits, current total
and free worker count getters need to be introduced. Client might also be
interested in the job queue length, so provide a getter for that too. As with
the other getters, preparing for the admin interface, mutual exclusion is used
within all getters.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Erik Skultety [Mon, 4 Apr 2016 20:32:16 +0000 (22:32 +0200)]
util: Use a mutex when retrieving threadpool data
So far, the values the affected getters retrieve are static, i.e. there's no
way of changing them during runtime. But admin interface will later enable
not only getting but changing them as well. So to prevent phenomenons like
torn reads or concurrent reads and writes of unaligned values, use mutual
exclusion when getting these values (writes do, understandably, use them
already).
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Erik Skultety [Thu, 25 Feb 2016 11:45:32 +0000 (12:45 +0100)]
util: Refactor thread creation by introducing virThreadPoolExpand
When either creating a threadpool, or creating a new thread to accomplish a job
that had been placed into the jobqueue, every time thread-specific data need to
be allocated, threadpool needs to be (re)-allocated and thread count indicators
updated. Make the code clearer to read by compressing these operations into a
more complex one.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Erik Skultety [Thu, 4 Feb 2016 14:23:00 +0000 (15:23 +0100)]
libvirt-host: Move virTypedParam* to libvirt-common
Commits 0472cef6, 9afc115f, 8cd1d546 exported typed params handlers internally,
but a commit which would move the public definition from libvirt-host to
libvirt-common was missing.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Peter Krempa [Wed, 13 Apr 2016 11:55:12 +0000 (13:55 +0200)]
event-test: Get rid of useless and ambiguous VIR_DEBUG macro
The event test does not try to include libvirt internals. Using a macro
named VIR_DEBUG might hint to such usage. Additionally it's useless
since it's used only in the main() function.
Modernize the message strings while touching them.
Jason J. Herne [Tue, 12 Apr 2016 14:13:27 +0000 (10:13 -0400)]
Libvirt: virTypedParamsValidate: Fix detection of multiple parameters
virTypedParamsValidate currently uses an index based check to find
duplicate parameters. This check does not work. Consider the following
simple example:
We have only 2 keys
A (multiples allowed)
B (multiples NOT allowed)
We are given the following list of parameters to check:
A
A
B
If you work through the validation loop you will see that our last iteration
through the loop has i=2 and j=1. In this case, i > j and keys[j].value.i will
indicate that multiples are not allowed. Both conditionals are satisfied so
an incorrect error will be given: "parameter '%s' occurs multiple times"
This patch replaces the index based check with code that remembers
the name of the last parameter seen and only triggers the error case if
the current parameter name equals the last one. This works because the
list is sorted and duplicate parameters will be grouped together.
In reality, we hit this bug while using selective block migration to migrate
a guest with 5 disks. 5 was apparently just the right number to push i > j
and hit this bug.
Dmitry Andreev [Thu, 17 Mar 2016 16:31:45 +0000 (19:31 +0300)]
qemu: migration: new migration param for persistent destination XML
Migration API allows to specify a destination domain configuration.
Offline domain has only inactive XML and it is replaced by configuration
specified using VIR_MIGRATE_PARAM_DEST_XML param. In case of live
migration VIR_MIGRATE_PARAM_DEST_XML param is applied for active XML.
This commit introduces the new VIR_MIGRATE_PARAM_PERSIST_XML param
that can be used within live migration to replace persistent/inactive
configuration.
Richard Laager [Thu, 24 Mar 2016 05:11:11 +0000 (00:11 -0500)]
ZFS: Support sparse volumes
By default, `zfs create -V ...` reserves space for the entire volsize,
plus some extra (which attempts to account for overhead).
If `zfs create -s -V ...` is used instead, zvols are (fully) sparse.
A middle ground (partial allocation) can be achieved with
`zfs create -s -o refreservation=... -V ...`. Both libvirt and ZFS
support this approach, so the ZFS storage backend should support it.
Signed-off-by: Richard Laager <rlaager@wiktel.com>
John Ferlan [Thu, 14 Apr 2016 14:21:27 +0000 (10:21 -0400)]
Resolve a couple of memory leaks
Commit id '4b75237f' seems to have triggered Coverity into finding
at least one memory leak in xen_xl.c for error path for cleanup where
the listenAddr would be leaked. Reviewing other callers, it seems that
qemu_parse_command.c would have the same issue, so just it too.
Jim Fehlig [Thu, 14 Apr 2016 22:10:32 +0000 (16:10 -0600)]
libxl: use LIBXL_API_VERSION 0x040200
To ensure the libvirt libxl driver will build with future versions
of Xen where the libxl API may change in incompatible ways,
explicitly use LIBXL_API_VERSION 0x040200. The libxl driver
does use new libxl APIs that have been added since Xen 4.2, but
currently it does not make use of any changes made to existing
APIs such as libxl_domain_create_restore or libxl_set_vcpuaffinity.
The version can be bumped if/when the libxl driver consumes the
changed APIs.
Further details can be found in the following discussion thread
https://www.redhat.com/archives/libvir-list/2016-April/msg00178.html Signed-off-by: Jim Fehlig <jfehlig@suse.com>
When creating the master key, we used mode 0600 (which we should) but
because we were creating it as root, the file is not readable by any
qemu running as non-root. Fortunately, it's just a matter of labelling
the file. We are generating the file path few times already, so let's
label it in the same function that has access to the path already.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Olga Krishtal [Mon, 11 Apr 2016 16:16:25 +0000 (19:16 +0300)]
storage: dir: adapt .uploadVol .dowloadVol for ploop volume
In case of ploop volume, target path of the volume is the path to the
directory that contains image file named root.hds and DiskDescriptor.xml.
While using uploadVol and downloadVol callbacks we need to open root.hds
itself.
Upload or download operations with ploop volume are only allowed when
images do not have snapshots. Otherwise operation fails.
Signed-off-by: Olga Krishtal <okrishtal@virtuozzo.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
Olga Krishtal [Mon, 11 Apr 2016 16:16:24 +0000 (19:16 +0300)]
storage: dir: adapt .refreshVol and .refreshPool for ploop volumes
Refreshes meta-information such as allocation, capacity, format, etc.
Ploop volumes differ from other volume types. Path to volume is the path
to directory with image file root.hds and DiskDescriptor.xml.
https://openvz.org/Ploop/format
Due to this fact, operations of opening the volume have to be done once
again. get the information.
To decide whether the given volume is ploops one, it is necessary to check
the presence of root.hds and DiskDescriptor.xml files in volumes' directory.
Only in this case the volume can be manipulated as the ploops one.
Such strategy helps us to resolve problems that might occure, when we
upload some other volume type from ploop source.
Signed-off-by: Olga Krishtal <okrishtal@virtuozzo.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
Olga Krishtal [Mon, 11 Apr 2016 16:16:20 +0000 (19:16 +0300)]
storage: dir: .buildVol and .buildVolFrom callbacks for ploop
These callbacks let us to create ploop volumes in dir, fs and etc. pools.
If a ploop volume was created via buildVol callback, then this volume
is an empty ploop device with DiskDescriptor.xml.
If the volume was created via .buildFrom - then its content is similar to
input volume content.
Signed-off-by: Olga Krishtal <okrishtal@virtuozzo.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
Olga Krishtal [Mon, 11 Apr 2016 16:16:19 +0000 (19:16 +0300)]
storage: add ploop volume type
Ploop image consists of directory with two files: ploop image itself,
called root.hds and DiskDescriptor.xml that contains information about
ploop device: https://openvz.org/Ploop/format.
Such volume are difficult to manipulate in terms of existing volume types
because they are neither a single files nor a directory.
This patch introduces new volume type - ploop. This volume type is used
by ploop volume's exclusively.
Signed-off-by: Olga Krishtal <okrishtal@virtuozzo.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Mon, 11 Apr 2016 15:00:26 +0000 (17:00 +0200)]
cfg.mk: Get rid of quotation tricks
To prevent the error messages in cfg.mk from triggering the very
same rules they're supposed to explain, we split the message in
the middle of a symbol name, ending up with stuff like
'I am a me'ssage
Instead of relying on these quotation tricks, simply exclude
cfg.mk from the relevant checks.
Peter Krempa [Wed, 6 Apr 2016 12:34:05 +0000 (14:34 +0200)]
qemu: command: Drop obsolete comment
The change that made qemu not add the memballoon by default happened
prior to 0.12.0. Additionaly the comment was misleading due to the code
that was added below. Since we always need to add a balloon on the
commandline drop the comment.
Move some API specific documentation out of -docs package and into
-devel, and some end user docs out of -devel and into -docs, then
drop the -devel dep on -docs. This is more in line with the suggested
Fedora guidelines.
Erik Skultety [Tue, 5 Apr 2016 19:04:06 +0000 (21:04 +0200)]
makefile: Move include/Makefile.am to include/libvirt/Makefile.am
The reason for this is to fix the automatic rebuild of libvirt-common.h.in.
All *.in files should be automatically rebuilt each time they're modified.
It works well for makefiles and pkgconfig files, since they do have a valid
dependency in the top-level Makefile. However, with libvirt-common.h.in
there is no dependency in the top-level Makefile and there's no need for it
either, so this rule
include/libvirt/libvirt-common.h: $(top_builddir)/config.status \
$(top_srcdir)/include/libvirt/libvirt-common.h.in
cd $(top_builddir) && $(SHELL) ./config.status $@
is never hit and should be moved to include/Makefile, but that's automake's
job. According to GNU automake docs:
"Files created by AC_CONFIG_FILES, be they
Automake Makefiles or not, are all removed by ‘make distclean’. Their inputs
are automatically distributed, unless they are the output of prior
AC_CONFIG_FILES commands. Finally, rebuild rules are generated in the Automake
Makefile existing in the subdirectory of the output file, if there is one, or
in the top-level Makefile otherwise."
Which means that if we want to have the rule for libvirt-common.h automatically
generated by automake, the include/Makefile.am needs to be moved into libvirt/
subdirectory and $SUBDIRS in the top-level Makefile need to be adjusted as
well. This patch moves Makefile.am from include/ to include/libvirt, adjusting
the prefixes accordingly as well as updates the top-level Makefile $SUBDIRS to
properly hint automake to generate all rules at proper places.
Best way to see the changes, use -M with 'git show'.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
vz: make it possible to use shared drivers API with vz driver connection
Since vz driver is now lives as a part of daemon we can benefit from
this fact and allow vz clients to use shared drivers API like storage,
network, nwfilter etc.
Laine Stump [Wed, 23 Mar 2016 19:49:29 +0000 (15:49 -0400)]
qemu: support new pci controller model "pcie-expander-bus"
This is backed by the qemu device pxb-pcie, which will be available in
qemu 2.6.0.
As with pci-expander-bus (which uses qemu's pxb device), the busNr
attribute and <node> subelement of <target> are used to set the bus_nr
and numa_node options.
During post-parse we validate that the domain's machinetype is
q35-based (since the device shows up for 440fx-based machinetypes, but
is unusable), as well as checking that <node> specifies a node that is
actually configured on the guest.
Laine Stump [Wed, 16 Mar 2016 17:37:14 +0000 (13:37 -0400)]
conf: new pci controller model pcie-expander-bus
This controller provides a single PCIe port on a new root. It is
similar to pci-expander-bus, intended to provide a bus that can be
associated with a guest-identifiable NUMA node, but is for
machinetypes with PCIe rather than PCI (e.g. q35-based machinetypes).
Aside from PCIe vs. PCI, the other main difference is that a
pci-expander-bus has a companion pci-bridge that is automatically
attached along with it, but pcie-expander-bus has only a single port,
and that port will only connect to a pcie-root-port, or to a
pcie-switch-upstream-port. In order for the bus to be of any use in
the guest, it must have either a pcie-root-port or a
pcie-switch-upstream-port attached (and one or more
pcie-switch-downstream-ports attached to the
pcie-switch-upstream-port).
Laine Stump [Tue, 8 Mar 2016 21:25:22 +0000 (16:25 -0500)]
qemu: add capabilities bit for device "pxb-pcie"
The pxb device is a PCIe expander bus that can be added to any
Q35-based machinetype. A single PCIe port (*not* hotpluggable) is
provided; if more than one device is desired, or if hotplug
support is needed, either a pcie-root-port, or some combination of
pcie-switch-upstream-port and pcie-swith-downstream-ports must be
added to it. It can have a NUMA node number associated with it, as
well as a bus number.
Laine Stump [Fri, 4 Mar 2016 19:35:20 +0000 (14:35 -0500)]
qemu: support new pci controller model "pci-expander-bus"
This is backed by the qemu device "pxb".
The pxb device always includes a pci-bridge that is at the bus number
of the pxb + 1.
busNr and <node> from the <target> subelement are used to set the
bus_nr and numa_node options for pxb.
During post-parse we validate that the domain's machinetype is
440fx-based (since the pxb device only works on 440fx-based machines),
and <node> also gets a sanity check to assure that the NUMA node
specified for the pxb (if any - it's optional) actually exists on the
guest.
Laine Stump [Fri, 4 Mar 2016 15:26:23 +0000 (10:26 -0500)]
conf: new pci controller model pci-expander-bus
This is a standard PCI root bus (not a bridge) that can be added to a
440fx-based domain. Although it uses a PCI slot, this is *not* how it
is connected into the PCI bus hierarchy, but is only used for
control. Each pci-expander-bus provides 32 slots (0-31) that can
accept hotplug of standard PCI devices.
The usefulness of pci-expander-bus relative to a pci-bridge is that
the NUMA node of the bus can be specified with the <node> subelement
of <target>. This gives guest-side visibility to the NUMA node of
attached devices (presuming that management apps only assign a device
to a bus that has a NUMA node number matching the node number of the
device on the host).
Each pci-expander-bus also has a "busNr" attribute. The expander-bus
itself will take the busNr specified, and all buses that are connected
to this bus (including the pci-bridge that is automatically added to
any expander bus of model "pxb" (see the next commit)) will use
busNr+1, busNr+2, etc, and the pci-root (or the expander-bus with next
lower busNr) will use bus numbers lower than busNr.
Laine Stump [Wed, 24 Feb 2016 21:40:49 +0000 (16:40 -0500)]
qemu: add capabilities bit for device "pxb"
The pxb device is a PCI expander bus that can be added to any
440fx-based machinetype. The PCI bus that is created has 32 standard
PCI slots (hotpluggable). It can have a NUMA node number associated
with it, as well as a bus number.
Laine Stump [Wed, 16 Mar 2016 18:20:52 +0000 (14:20 -0400)]
conf: utility function to convert PCI controller model into connect type
There are two places in qemu_domain_address.c where we have a switch
statement to convert PCI controller models
(VIR_DOMAIN_CONTROLLER_MODEL_PCI*) into the connection type flag that
is matched when looking for an upstream connection for that model of
controller (VIR_PCI_CONNECT_TYPE_*). This patch makes a utility
function in conf/domain_addr.c to do that, so that when a new PCI
controller is added, we only need to add the new model-->connect-type
in a single place.
Laine Stump [Tue, 15 Mar 2016 19:49:22 +0000 (15:49 -0400)]
conf/qemu: change the way VIR_PCI_CONNECT_TYPE_* flags work
The flags used to determine which devices could be plugged into which
controllers were quite confusing, as they tried to create classes of
connections, then put particular devices into possibly multiple
classes, while sometimes setting multiple flags for the controllers
themselves. The attempt to have a single flag indicate, e.g. that a
root-port or a switch-downstream-port could connect was not only
confusing, it was leading to a situation where it would be impossible
to specify exactly the right combinations for a new controller.
The solution is for the VIR_PCI_CONNECT_TYPE_* flags to have a 1:1
correspondence with each type of PCI controller, plus a flag for a PCI
endpoint device and another for a PCIe endpoint device (the only
exception to this is that pci-bridge and pcie-expander-bus controllers
have their upstream connection classified as
VIR_PCI_CONNECT_TYPE_PCI_DEVICE since they can be plugged into
*exactly* the same ports as any endpoint device). Each device then
has a single flag for connect type (plus the HOTPLUG flag if that
device can e hotplugged), and each controller sets the CONNECT bits
for all controllers that can be plugged into it, as well as for either
type of endpoint device that can be plugged in (and the HOTPLUG flag
if it can accept hotplugged devices).
With this change, it is *slightly* easier to understand the matching
of connections (as long as you remember that the flag for a
device/upstream-facing connection of a controller is the same as that
device's type, while the flags for a controller's downstream
connections is the OR of all device types that can be plugged into
that controller). More importantly, it will be possible to correctly
specify what can be plugged into a pcie-switch-expander-bus, when
support for it is added.
Laine Stump [Wed, 2 Mar 2016 20:29:33 +0000 (15:29 -0500)]
conf: allow use of slot 0 in a dmi-to-pci-bridge
When support for dmi-to-pci-bridge was added, it was assumed that,
just as with the pci-root bus, slot 0 was reserved. This is not the
case - it can be used to connect a device just like any other slot, so
remove the restriction and update the test cases that auto-assign an
address on a dmi-to-pci-bridge.
Laine Stump [Wed, 2 Mar 2016 20:31:02 +0000 (15:31 -0500)]
conf: use #define instead of literal for highest slot in upstream port
Every other maxSlot was either set to 0 or to
VIR_PCI_ADDRESS_SLOT_LAST, but this one was for some reason set to the
literal value 31 (which is the same as VIR_PCI_ADDRESS_SLOT_LAST).
This makes them all consistent.
Laine Stump [Tue, 22 Mar 2016 16:24:08 +0000 (12:24 -0400)]
schema: allow pci address attributes to be in decimal
This is especially useful for "bus", since the bus of a device's pci
address is matched to the "index" of a controller to determine which
bus it will be connected to, and "index" is always specified in
decimal - being able to specify both in decimal at least makes it
easier to assure a device is being assigned to the correct bus when it
is added. For the other attributes, it is just a convenience.
(MB: the parser already allows for any of these attributes to be given
in decimal, and there are even examples floating around on the
internet that give them in decimal rather than hex (written in the
days before virsh did schema validation on all XML). This only updates
the schema to match the parser.)
Laine Stump [Tue, 22 Mar 2016 16:00:40 +0000 (12:00 -0400)]
schema: rename uint8range/uint24range to uint8/uint24
nwfilter.rng defines uint16range and uint32range, but in a different
manner (it also allows a variable name as the value, rather than just
a decimal or hex number). I wanted to add uint16range to
basictypes.rng, but my desired definition was parallel to those for
uint8range and uint24range which are defined in basictypes.rng - they
*don't* allow a variable name for the value.
The simplest path to make everyone happy is to make the "plain"
versions in basictypes.rng have simpler names - "uint8", "uint16", and
"uint24". This patch renames uint8range and uint24range to uint8 and
uint24, while the next patch will add uint16.
Laine Stump [Tue, 22 Mar 2016 15:38:53 +0000 (11:38 -0400)]
schema: make pci slot and function optional
The pcie-switch-downstream-port and pcie-root-port controllers have
only a single slot, numbered 0, and the greate majority of all guest
PCI devices are plugged into function 0 of whatever slot they're
using. The parser makes these optional, setting them to 0 when not
specified, and it's logical for the schema to also make them optional.
Take setlocale/gettext error handling pattern from tools/virsh-*
and use it for all standalone binaries via a new shared
virGettextInitialize routine. The virsh* pattern differed slightly
from other callers. All users now consistently:
* Ignore setlocale errors. virsh has done this forever, presumably for
good reason. This has been partially responsible for some bug reports:
We use device-mapper to enumerate all dm devices, and filter out
the list of multipath devices by checking the target_type string
name. The code however cancels all scanning if we encounter
target_type=NULL
I don't know how to reproduce that situation, but a user was hitting
it in their setup, and inspecting the lvm2/device-mapper code shows
many places where !target_type is explicitly ignored and processing
continues on to the next device. So I think we should do the same
The watchdog cli refactoring in 4666b762 dropped the temporary variable
we use to convert to action=dump to action=pause for the qemu cli, and
stored the converted value in the domain structure. Our other watchdog
handling code then treated it as though the user requested action=pause,
which broke action=dump handling.
test: genericxml2xml: test graphics listen= compat
* Add a test for listen=XXX and <listen address=YYY/> collision error
* Add an explicit test for listen=XXX duplicated to <listen address=XXX/>
We implicitly test it elsewhere but I figure it's better to be explicit,
and this test case can be extended in the future for additional listen
back compat if/when we support <listen type='socket'/> syntax
projects / libvirt.git / log