[libvirt] [PATCH 00/11] storage: modularize the storage driver backends
by Peter Krempa
Split up the storage driver backends into loadable modules so that
binary distributions don't have to compromise on shipping the storage
driver with all backends which may pull in too many dependencies.
Peter Krempa (11):
configure: Fix configure output for RBD storage backend
tests: storagepoolxml2xml: Remove compile conditionals
tests: drivermodule: Drop unused macro arguments
driver: Split/refactor driver module loading
daemon: Refactor connection driver module loading
storage: backend: Refactor registration of the backend drivers
storage: Turn driver backends into (static) modules
storage: Turn storage backends into dynamic modules
tests: drivermodule: Make sure that all compiled storage backends can
be loaded
spec: Modularize the storage driver
news: Mention storage driver split
daemon/libvirtd.c | 136 +++++++++-------------
docs/news.xml | 10 ++
libvirt.spec.in | 185 +++++++++++++++++++++++++-----
m4/virt-storage-rbd.m4 | 2 +-
src/Makefile.am | 199 ++++++++++++++++++++++++++++++---
src/driver.c | 136 ++++++++++++++--------
src/driver.h | 6 +-
src/libvirt_driver_modules.syms | 1 +
src/storage/storage_backend.c | 151 +++++++++++++++++++------
src/storage/storage_backend.h | 5 +
src/storage/storage_backend_disk.c | 7 ++
src/storage/storage_backend_disk.h | 4 +-
src/storage/storage_backend_fs.c | 27 +++++
src/storage/storage_backend_fs.h | 11 +-
src/storage/storage_backend_gluster.c | 13 ++-
src/storage/storage_backend_gluster.h | 5 +-
src/storage/storage_backend_iscsi.c | 7 ++
src/storage/storage_backend_iscsi.h | 4 +-
src/storage/storage_backend_logical.c | 7 ++
src/storage/storage_backend_logical.h | 4 +-
src/storage/storage_backend_mpath.c | 8 ++
src/storage/storage_backend_mpath.h | 4 +-
src/storage/storage_backend_rbd.c | 7 ++
src/storage/storage_backend_rbd.h | 4 +-
src/storage/storage_backend_scsi.c | 7 ++
src/storage/storage_backend_scsi.h | 4 +-
src/storage/storage_backend_sheepdog.c | 7 ++
src/storage/storage_backend_sheepdog.h | 4 +-
src/storage/storage_backend_vstorage.c | 7 ++
src/storage/storage_backend_vstorage.h | 4 +-
src/storage/storage_backend_zfs.c | 7 ++
src/storage/storage_backend_zfs.h | 4 +-
src/storage/storage_driver.c | 19 +++-
src/storage/storage_driver.h | 1 +
tests/Makefile.am | 4 +-
tests/storagepoolxml2xmltest.c | 6 -
tests/virdrivermoduletest.c | 52 +++++----
tests/virstoragetest.c | 4 +
38 files changed, 788 insertions(+), 285 deletions(-)
--
2.11.0
7 years, 9 months
[libvirt] [RFC] finegrained disk driver options control
by Denis V. Lunev
Hello, All!
There is a problem in the current libvirt implementation. domain.xml
allows to specify only basic set of options, especially in the case
of QEMU, when there are really a lot of tweaks in format drivers.
Most likely these options will never be supported in a good way
in libvirt as recognizable entities.
Right now in order to debug libvirt QEMU VM in production I am using
very strange approach:
- disk section of domain XML is removed
- exact command line options to start the disk are specified at the end
of domain.xml whithin <qemu:commandline> as described by Stefan
http://blog.vmsplice.net/2011/04/how-to-pass-qemu-command-line-options.html
The problem is that when debug is finished and viable combinations of
options is found I can not drop VM in such state in the production. This
is the pain and problem. For example, I have spend 3 days with the
VM of one customer which blames us for slow IO in the guest. I have
found very good combination of non-standard options which increases
disk performance 5 times (not 5%). Currently I can not put this combination
in the production as libvirt does not see the disk.
I propose to do very simple thing, may be I am not the first one here,
but it would be nice to allow to pass arbitrary option to the QEMU
command line. This could be done in a very generic way if we will
allow to specify additional options inside <driver> section like this:
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2' cache='none' io='native'
iothread='1'>
<option name='l2-cache-size' value='64M/>
<option name='cache-clean-interval' value='32'/>
</driver>
<source file='/var/lib/libvirt/images/rhel7.qcow2'/>
<target dev='sda' bus='scsi'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
and so on. The meaning (at least for QEMU) is quite simple -
these options will just be added to the end of the -drive command
line. The meaning for other drivers should be the same and I
think that there are ways to pass generic options in them.
Any opinion?
Den
7 years, 9 months
[libvirt] [PATCH] qemu: Don't try to update undefined guest CPU
by Jiri Denemark
Calling virCPUUpdateLive on a domain with no guest CPU configuration
does not make sense. Especially when doing so would crash libvirtd.
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
---
src/qemu/qemu_process.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 780f9587a..ec0e36d2e 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -3815,11 +3815,6 @@ qemuProcessVerifyCPUFeatures(virDomainDefPtr def,
{
int rc;
- if (!def->cpu ||
- (def->cpu->mode == VIR_CPU_MODE_CUSTOM &&
- !def->cpu->model))
- return 0;
-
rc = virCPUCheckFeature(def->os.arch, def->cpu, "invtsc");
if (rc < 0) {
@@ -3870,6 +3865,13 @@ qemuProcessUpdateLiveGuestCPU(virQEMUDriverPtr driver,
qemuProcessVerifyHypervFeatures(def, cpu) < 0)
goto cleanup;
+ if (!def->cpu ||
+ (def->cpu->mode == VIR_CPU_MODE_CUSTOM &&
+ !def->cpu->model)) {
+ ret = 0;
+ goto cleanup;
+ }
+
if (qemuProcessVerifyCPUFeatures(def, cpu) < 0)
goto cleanup;
--
2.12.0
7 years, 9 months
Re: [libvirt] [PATCH 2/2] qemu: Validate the domain after marking the current domain as transient
by Daniel P. Berrange
On Wed, Mar 08, 2017 at 10:32:32AM +0100, Marc Hartmayer wrote:
> On Mon, Feb 27, 2017 at 11:20 AM +0100, "Daniel P. Berrange" <berrange(a)redhat.com> wrote:
> > On Mon, Feb 27, 2017 at 10:59:39AM +0100, Marc Hartmayer wrote:
> >> On Thu, Feb 23, 2017 at 05:36 PM +0100, "Daniel P. Berrange" <berrange(a)redhat.com> wrote:
> >> > On Thu, Feb 23, 2017 at 05:22:44PM +0100, Marc Hartmayer wrote:
> >> >> On Thu, Feb 23, 2017 at 03:33 PM +0100, Michal Privoznik <mprivozn(a)redhat.com> wrote:
> >> >> > On 02/23/2017 10:44 AM, Marc Hartmayer wrote:
> >> >> >> Validate the domain that actually will be started. It's semantically
> >> >> >> more clear and also it can detect failures that may have happened in
> >> >> >> virDomainObjSetDefTransient().
> >> >> >>
> >> >> >> Signed-off-by: Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com>
> >> >> >> Reviewed-by: Bjoern Walk <bwalk(a)linux.vnet.ibm.com>
> >> >> >> Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.vnet.ibm.com>
> >> >> >> ---
> >> >> >> src/qemu/qemu_process.c | 6 +++---
> >> >> >> 1 file changed, 3 insertions(+), 3 deletions(-)
> >> >> >>
> >> >> >> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
> >> >> >> index a57d136..bd3a8b8 100644
> >> >> >> --- a/src/qemu/qemu_process.c
> >> >> >> +++ b/src/qemu/qemu_process.c
> >> >> >> @@ -4746,9 +4746,6 @@ qemuProcessInit(virQEMUDriverPtr driver,
> >> >> >> vm->def->os.machine)))
> >> >> >> goto cleanup;
> >> >> >>
> >> >> >> - if (qemuProcessStartValidate(driver, vm, priv->qemuCaps, caps, flags) < 0)
> >> >> >> - goto cleanup;
> >> >> >> -
> >> >> >> /* Do this upfront, so any part of the startup process can add
> >> >> >> * runtime state to vm->def that won't be persisted. This let's us
> >> >> >> * report implicit runtime defaults in the XML, like vnc listen/socket
> >> >> >> @@ -4757,6 +4754,9 @@ qemuProcessInit(virQEMUDriverPtr driver,
> >> >> >> if (virDomainObjSetDefTransient(caps, driver->xmlopt, vm) < 0)
> >> >> >> goto cleanup;
> >> >> >>
> >> >> >> + if (qemuProcessStartValidate(driver, vm, priv->qemuCaps, caps, flags) < 0)
> >> >> >> + goto cleanup;
> >> >> >> +
> >> >> >
> >> >> > This needs to be goto stop for the reasons described in the previous e-mail.
> >> >> >
> >> >> >> if (flags & VIR_QEMU_PROCESS_START_PRETEND) {
> >> >> >> if (qemuDomainSetPrivatePaths(driver, vm) < 0)
> >> >> >> goto cleanup;
> >> >> >>
> >> >> >
> >> >> > Honestly, I like what we have now better. I mean, SetDefTransient() is
> >> >> > very unlikely to fail. It's just doing a copy of domain definition (in a
> >> >> > very stupid way, but lets save that for a different discussion).
> >> >> > Basically, it will fail on OOM only (which you will not get on a Linux
> >> >> > system, unless you really try).
> >> >>
> >> >> It's semantically more clear (at least for me) and for example it
> >> >> enables us to change some parts of the transient domain before
> >> >> validation (affect the transient domain only, not the persistent).
> >> >
> >> > What are you planning to change in the config before validation ?
> >> >
> >>
> >> I'm implementing a feature which allows to select the boot device at
> >> domain start time (something like 'virsh start --with-bootdevice sda
> >> domain1'). The main reason why we want this is because the s390
> >> architecture boots only from the first device specified in the boot
> >> order.
> >
> > There's no need to changes in the QEMU driver todo this. You can just
> > query the current XML config, change the boot device in it, and then
> > run virDomainCreateXML to launch the guest with the changed config,
> > or virDomainDefineXML again to make the changed boot device permanent.
> >
>
> First of all, I hope I understand you right :) (you can tell me as soon
> as you have read the following text)
>
> I've followed your advice and tried to add this functionality without
> any changes in the QEMU/hypervisor. For this I've created a new function
> in the remote driver which will call the needed functions (get current
> XML config for the domain, manipulate the XML config, and then use
> virDomainCreateXML for starting).
>
> To get the current XML config is straightforward as you've mentioned -
> just use 'virDomanGetXMLDesc(...)'.
>
> But how can I change the boot device?
> 1) I could use libxml2 for manipulating the XML string which we will get
> with calling 'virDomainGetXMLDesc(..)' but this is error-prone and just
> duplicate work as we have to parse the XML string and the information of
> it. Also, if there are any additions in the future for boot devices
> there will be no 'compile time reminder' that you have to edit this
> function.
Yes, this is the way it is normally done. There is a tradeoff here between
wanting to be reminded at compile time but seeing build breakage, and libvirt
wanting to be able to extend its config info without breaking apps. The
libvirt view is that the latter is more important.
> or
> 2) Parse the XML string into our internal representation (virDomainDef),
> adjust the boot orders and create a new XML string out of this internal
> representation (reverse to the way how virDomainDefCopy(...) works). But
> there is the huge problem:
>
> We need 'virCapsPtr caps' and 'virDomainXMLOptionPtr xmlopt' for
> virDomainDefFormat(...) and virDomainDefParseString(...) but we're on
> the remote driver layer and therefore we've no direct access to this. We
> could add a function to the hypervisor driver interface for getting
> these but this is just awkward.
The virDomainDef are private data structures just for internal libvirt
usage. Even though virsh is in the libvirt source tree, it should be
treated as if it were a standalone application and thus only use the
public APIs.
> So my question to you is: do you have a better idea for this?
>
> Many thanks in advance.
>
> PS. I hope it's okay for you that I'm writing to you only for the moment
> (as it's somehow off topic). If not I'll send it to the mailing list :)
It isn't off-topic, so I'm copying back in the list.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
7 years, 9 months
[libvirt] [PATCH 0/3] log|lock daemon: Don't spam logs with IO error messages after client disconnects
by Peter Krempa
See patch 3 for explanation
Peter Krempa (3):
rpc: socket: Add possibility to suppress errors on read hangup
rpc: serverclient: Add option to suppress errors on EOF
(log|lock)daemon: Don't spam logs with IO error messages after client
disconnects
src/locking/lock_daemon.c | 3 +++
src/logging/log_daemon.c | 3 +++
src/rpc/virnetserverclient.c | 13 +++++++++++++
src/rpc/virnetserverclient.h | 2 ++
src/rpc/virnetsocket.c | 33 +++++++++++++++++++++++++++------
src/rpc/virnetsocket.h | 2 ++
6 files changed, 50 insertions(+), 6 deletions(-)
--
2.12.0
7 years, 9 months
[libvirt] [REPOST PATCH 0/4] Split out storage object into its own module
by John Ferlan
Repost after merging with latest changes of:
http://www.redhat.com/archives/libvir-list/2017-March/msg00305.html
Continuing down the pile of drivers from my RFC for making a common pool
object - we're now at storage... For reference see patch 3 of:
http://www.redhat.com/archives/libvir-list/2017-February/msg00519.html
This series works through the storage conf adjustments. This pile is
fairly straightforward. The virStorageVol* API's make it a bit more
interesting, but like other series we split out anything referencing
virStoragePoolObj and go from there.
John Ferlan (4):
conf: Introduce virstorageobj
conf: Adjust coding style for storage conf sources
conf: Alter coding style of storage conf function prototypes
conf: Use consistent function name prefixes for virstorageobj
po/POTFILES.in | 1 +
src/Makefile.am | 3 +-
src/conf/storage_conf.c | 975 ++---------------------------------------
src/conf/storage_conf.h | 174 ++------
src/conf/virstorageobj.c | 997 ++++++++++++++++++++++++++++++++++++++++++
src/conf/virstorageobj.h | 156 +++++++
src/libvirt_private.syms | 34 +-
src/storage/storage_backend.h | 2 +-
src/storage/storage_driver.c | 24 +-
src/storage/storage_driver.h | 2 +-
src/storage/storage_util.h | 1 -
src/test/test_driver.c | 1 +
12 files changed, 1263 insertions(+), 1107 deletions(-)
create mode 100644 src/conf/virstorageobj.c
create mode 100644 src/conf/virstorageobj.h
--
2.9.3
7 years, 9 months
[libvirt] [PATCH 0/4] Split out storage object into its own module
by John Ferlan
Continuing down the pile of drivers from my RFC for making a common pool
object - we're now at storage... For reference see patch 3 of:
http://www.redhat.com/archives/libvir-list/2017-February/msg00519.html
This series works through the storage conf adjustments. This pile is
fairly straightforward. The virStorageVol* API's make it a bit more
interesting, but like other series we split out anything referencing
virStoragePoolObj and go from there.
John Ferlan (4):
conf: Introduce virstorageobj
conf: Adjust coding style for storage conf sources
conf: Alter coding style of storage conf function prototypes
conf: Use consistent function name prefixes for virstorageobj
po/POTFILES.in | 1 +
src/Makefile.am | 3 +-
src/conf/storage_conf.c | 965 ++---------------------------------------
src/conf/storage_conf.h | 174 ++------
src/conf/virstorageobj.c | 986 ++++++++++++++++++++++++++++++++++++++++++
src/conf/virstorageobj.h | 156 +++++++
src/libvirt_private.syms | 34 +-
src/storage/storage_backend.h | 2 +-
src/storage/storage_driver.c | 24 +-
src/storage/storage_driver.h | 2 +-
src/storage/storage_util.h | 1 -
src/test/test_driver.c | 1 +
12 files changed, 1255 insertions(+), 1094 deletions(-)
create mode 100644 src/conf/virstorageobj.c
create mode 100644 src/conf/virstorageobj.h
--
2.9.3
7 years, 9 months
[libvirt] [PATCH v2 0/4] qemu: Add support for generic PCIe Root Ports
by Andrea Bolognani
Blurby McBlurbface.
Andrea Bolognani (4):
qemu: Add support for generic PCIe Root Ports
qemu: Use generic PCIe Root Ports by default when available
tests: Test generic PCIe Root Ports
news: Document support for generic PCIe Root Ports
docs/news.xml | 10 ++++++
docs/schemas/domaincommon.rng | 1 +
src/conf/domain_conf.c | 4 ++-
src/conf/domain_conf.h | 1 +
src/qemu/qemu_capabilities.c | 2 ++
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 18 ++++++++--
src/qemu/qemu_domain_address.c | 13 +++++--
tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 1 +
.../qemuxml2argv-pcie-root-port-model-generic.args | 22 ++++++++++++
.../qemuxml2argv-pcie-root-port-model-generic.xml | 22 ++++++++++++
.../qemuxml2argv-pcie-root-port-model-ioh3420.args | 21 ++++++++++++
.../qemuxml2argv-pcie-root-port-model-ioh3420.xml | 19 ++++++++++
tests/qemuxml2argvtest.c | 14 ++++++++
...qemuxml2xmlout-pcie-root-port-model-generic.xml | 40 ++++++++++++++++++++++
...qemuxml2xmlout-pcie-root-port-model-ioh3420.xml | 35 +++++++++++++++++++
tests/qemuxml2xmltest.c | 14 ++++++++
17 files changed, 231 insertions(+), 7 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pcie-root-port-model-generic.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pcie-root-port-model-generic.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pcie-root-port-model-ioh3420.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pcie-root-port-model-ioh3420.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-pcie-root-port-model-generic.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-pcie-root-port-model-ioh3420.xml
--
2.7.4
7 years, 9 months
[libvirt] [PATCH v1 0/2] libvirt-python: virEventAsyncIOImpl (was: libvirtaio)
by Wojtek Porczyk
Hello,
As promised, this is the event loop implementation which dispatches the
callbacks via asyncio's event loop.
There are two patches: the first one fixes the bug around freeing opaque
objects [1][2], and the second one is the actual implementation.
Compared to standalone version I did earlier, this has public names more
similar in style to other functions in the module. Also some comments are
corrected, and packaging code is lightly touched.
[1] https://www.redhat.com/archives/libvir-list/2017-January/msg00863.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1433028
Wojtek Porczyk (2):
Allow for ff callbacks to be called by custom event implementations
Add asyncio event loop implementation
libvirt-override.c | 36 ++---
libvirt-override.py | 45 ++++++
libvirt-python.spec.in | 1 +
libvirtaio.py | 398 +++++++++++++++++++++++++++++++++++++++++++++++++
sanitytest.py | 5 +-
setup.py | 12 ++
6 files changed, 471 insertions(+), 26 deletions(-)
create mode 100644 libvirtaio.py
--
pozdrawiam / best regards _.-._
Wojtek Porczyk .-^' '^-.
Invisible Things Lab |'-.-^-.-'|
| | | |
I do not fear computers, | '-.-' |
I fear lack of them. '-._ : ,-'
-- Isaac Asimov `^-^-_>
7 years, 9 months
[libvirt] [PATCH 00/12] qemu: Enforce guest CPU specification
by Jiri Denemark
When starting a domain with custom guest CPU specification QEMU may add
or remove some CPU features. There are several reasons for this, e.g.,
QEMU/KVM does not support some requested features or the definition of
the requested CPU model in libvirt's cpu_map.xml differs from the one
QEMU is using. We can't really avoid this because CPU models are allowed
to change with machine types and libvirt doesn't know (and probably
doesn't even want to know) about such changes.
Thus when we want to make sure guest ABI doesn't change when a domain
gets migrated to another host, we need to update our live CPU definition
according to the CPU QEMU created. Once updated, we will change CPU
checking to VIR_CPU_CHECK_FULL to make sure the virtual CPU created
after migration exactly matches the one on the source.
https://bugzilla.redhat.com/show_bug.cgi?id=822148
https://bugzilla.redhat.com/show_bug.cgi?id=824989
Jiri Denemark (12):
tests: Switch to sparse initialization of virCPUDef
docs: Clarify /domain/cpu/@match description
Introduce /domain/cpu/@check XML attribute
qemu: Set default values for CPU check attribute
qemu: Refactor Hyper-V features check
qemu: Refactor KVM features check
qemu: Refactor CPU features check
qemu: Refactor qemuProcessVerifyGuestCPU
qemu: Use ARCH_IS_X86 in qemuMonitorJSONGetGuestCPU
qemu: Ask QEMU for filtered CPU features
qemu: Update CPU definition according to QEMU
qemu: Enforce guest CPU specification
docs/formatdomain.html.in | 52 ++++-
docs/schemas/cputypes.rng | 10 +
docs/schemas/domaincommon.rng | 3 +
src/conf/cpu_conf.c | 30 +++
src/conf/cpu_conf.h | 12 ++
src/conf/domain_conf.c | 21 ++
src/cpu/cpu.c | 45 +++++
src/cpu/cpu.h | 12 ++
src/cpu/cpu_x86.c | 105 ++++++++++
src/libvirt_private.syms | 1 +
src/qemu/qemu_domain.c | 42 ++++
src/qemu/qemu_monitor.c | 11 +-
src/qemu/qemu_monitor.h | 3 +-
src/qemu/qemu_monitor_json.c | 38 +++-
src/qemu/qemu_monitor_json.h | 3 +-
src/qemu/qemu_process.c | 225 +++++++++++++--------
tests/domaincapstest.c | 38 ++--
tests/qemumonitorjsontest.c | 4 +-
.../qemuxml2argv-aarch64-gic-host.xml | 2 +-
.../qemuxml2argv-aarch64-gic-v2.xml | 2 +-
.../qemuxml2argv-aarch64-gic-v3.xml | 2 +-
.../qemuxml2argv-cpu-check-default-none.args | 21 ++
.../qemuxml2argv-cpu-check-default-none.xml | 19 ++
.../qemuxml2argv-cpu-check-default-none2.args | 21 ++
.../qemuxml2argv-cpu-check-default-none2.xml | 21 ++
.../qemuxml2argv-cpu-check-default-partial.args | 22 ++
.../qemuxml2argv-cpu-check-default-partial.xml | 19 ++
.../qemuxml2argv-cpu-check-default-partial2.args | 21 ++
.../qemuxml2argv-cpu-check-default-partial2.xml | 21 ++
.../qemuxml2argv-cpu-check-full.args | 1 +
.../qemuxml2argv-cpu-check-full.xml | 21 ++
.../qemuxml2argv-cpu-check-none.args | 21 ++
.../qemuxml2argv-cpu-check-none.xml | 21 ++
.../qemuxml2argv-cpu-check-partial.args | 1 +
.../qemuxml2argv-cpu-check-partial.xml | 21 ++
tests/qemuxml2argvtest.c | 8 +
.../qemuxml2xmlout-aarch64-aavmf-virtio-mmio.xml | 2 +-
...qemuxml2xmlout-aarch64-video-virtio-gpu-pci.xml | 2 +-
.../qemuxml2xmlout-aarch64-virtio-pci-default.xml | 2 +-
...2xmlout-aarch64-virtio-pci-manual-addresses.xml | 2 +-
.../qemuxml2xmlout-cpu-check-default-none.xml | 28 +++
.../qemuxml2xmlout-cpu-check-default-none2.xml | 30 +++
.../qemuxml2xmlout-cpu-check-default-partial.xml | 30 +++
.../qemuxml2xmlout-cpu-check-default-partial2.xml | 30 +++
.../qemuxml2xmlout-cpu-check-full.xml | 30 +++
.../qemuxml2xmlout-cpu-check-none.xml | 30 +++
.../qemuxml2xmlout-cpu-check-partial.xml | 30 +++
.../qemuxml2xmlout-cpu-eoi-disabled.xml | 2 +-
.../qemuxml2xmlout-cpu-eoi-enabled.xml | 2 +-
.../qemuxml2xmlout-cpu-host-kvmclock.xml | 2 +-
.../qemuxml2xmlout-cpu-host-model-features.xml | 2 +-
...emuxml2xmlout-cpu-host-passthrough-features.xml | 2 +-
.../qemuxml2xmlout-cpu-kvmclock.xml | 2 +-
.../qemuxml2xmlout-graphics-spice-timeout.xml | 2 +-
tests/qemuxml2xmltest.c | 8 +
tests/testutilsqemu.c | 48 ++---
56 files changed, 1039 insertions(+), 167 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-default-none.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-default-none.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-default-none2.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-default-none2.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-default-partial.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-default-partial.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-default-partial2.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-default-partial2.xml
create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-full.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-full.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-none.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-none.xml
create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-partial.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-partial.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-check-default-none.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-check-default-none2.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-check-default-partial.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-check-default-partial2.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-check-full.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-check-none.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-check-partial.xml
--
2.12.0
7 years, 9 months