So far all the properties we are trying to fetch are device
properties, i.e. -device $dev on qemu command line. Change
misleading variable names to express what's queried for better.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The current private XML parsing code relies on the assumption
that NUMA node IDs start from 0 and are densely allocated,
neither of which is necessarily the case.
Change it so that the bitmap size is dynamically calculated by
looking at NUMA node IDs instead, which ensures all nodes will
be able to fit and thus the bitmap will be parsed successfully.
Update one of the test cases so that it would fail with the
previous approach, but passes with the new one.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1490158
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Allocated in qemuMigrationParamsNew() we need to free
priv->job.migParams when no longer needed.
==8061== 234 (192 direct, 42 indirect) bytes in 1 blocks are definitely lost in loss record 112 of 123
==8061== at 0x4C2CF26: calloc (vg_replace_malloc.c:711)
==8061== by 0x5325D05: virAlloc (viralloc.c:144)
==8061== by 0x1984F9: qemuMigrationParamsNew (qemu_migration_params.c:218)
==8061== by 0x19A352: qemuMigrationParamsParse (qemu_migration_params.c:1185)
==8061== by 0x1604D8: qemuDomainObjPrivateXMLParseJob (qemu_domain.c:2390)
==8061== by 0x160AE9: qemuDomainObjPrivateXMLParse (qemu_domain.c:2517)
==8061== by 0x5419EAE: virDomainObjParseXML (domain_conf.c:20442)
==8061== by 0x541A25E: virDomainObjParseNode (domain_conf.c:20555)
==8061== by 0x541A2FC: virDomainObjParseFile (domain_conf.c:20574)
==8061== by 0x13607D: testCompareStatusXMLToXMLFiles (qemuxml2xmltest.c:75)
==8061== by 0x14F3E8: virTestRun (testutils.c:180)
==8061== by 0x14DCD0: mymain (qemuxml2xmltest.c:1200)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Historically we have relied on autopoint/gettextize to install a
standard po/Makefile.in.in. There is very limited scope for customizing
this and it also causes a bunch of extra stuff to be pulled into
configure.ac which potentially clashes with gnulib. Writing make rules
for po file management is no more difficult than any other rules libvirt
has, so stop using autopoint/gettextize.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The disk cache mode translates to various frontend and backend
attributes for the qemu block layer. For the frontend device the
'writeback' parameter is used and provided as 'write-cache'. Implement
this so that we can later switch to using -blockdev where we will not
pass the cachemode directly any more.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
QEMU translates the cache mode of a disk internally into 3 flags.
'write-cache' is a flag of the frontend while others are flag of the
backing storage. Add capability which will allow expressing it via the
frontend attribute.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Add helper which will map values of disk cache mode to the flags which
are accepted by various parts of the qemu block layer.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Current script confuses on lines like this:
static virHypervisorDriver parallelsHypervisorDriver;
It interprets next lines as if there is open brace.
Let's filter this case from matches.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Broken by [1] commit - trailing comma instead of semicolon. Fortunately
the issue did not get sneak in released 4.2 version. Note that uriSchemes
for parallelsConnectDriver should not be allocated on stack.
[1] 8e4f9a27: "driver: declare supported URI schemes in virConnectDriver struct"
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When qemu does not support changing of the backing store string, we'd
reaport that block pull is not supported instead of block commit.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Drop the checking of 'shared' from the ABI stability check. This
property controls whether the hypervisor allows concurrent access to the
same file, but this fact does not influence guest ABI.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Currently it is not used in backing chains and does not seem that we
will need to use it so return it back to the disk definition. Thankfully
most accesses are done via the accessors.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Replace direct usage of disk->src->driverName with the existing
accessors. The parser code where we assign the driver from XML is
intentionally not fixed to save an allocation.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
There were two places where we'd check this independently. Move it to
the disk definition validation callback. This also fixes possible use of
NULL in a printf for network storage.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
On Core i5 650 x86_64 kvm guest fail to start with error [1] for next cpu config:
<cpu mode='host-model' check='partial'>
<model fallback='allow'/>
<feature policy='require' name='x2apic'/>
</cpu>
The problem is in full CPU calculation in virQEMUCapsInitHostCPUModel.
It is supposed to include features emulated by qemu and missed on host. Some of
such features may be not included however.
For Core i5 650 host CPU is detected as Westmere and reported CPU as
SandyBridge. x2apic is missed on host and provided by installed qemu. The
feature is not mentioned in reported CPU features explicitly because SandyBridge
model include it. As a result full CPU does not include x2apic too.
Solution is to expand guest cpu features before updating fullCPU features.
[1] error: the CPU is incompatible with host CPU: \
Host CPU does not provide required features: x2apic
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Add a function named virDomainObjCheckIsActive in src/conf/domain_conf.c.
It calls virDomainObjIsActive, raises error if necessary and returns.
There is a lot of occurence of this pattern and it will save 3 lines on
each call.
Signed-off-by: Clementine Hayat <clem@lse.epita.fr>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Our virObject code relies heavily on the fact that the first
member of the class struct is type of virObject (or some
derivation of if). Let's check for that.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
So far we are repeating the following lines over and over:
if (!(virSomeObjectClass = virClassNew(virClassForObject(),
"virSomeObject",
sizeof(virSomeObject),
virSomeObjectDispose)))
return -1;
While this works, it is impossible to do some checking. Firstly,
the class name (the 2nd argument) doesn't match the name in the
code in all cases (the 3rd argument). Secondly, the current style
is needlessly verbose. This commit turns example into following:
if (!(VIR_CLASS_NEW(virSomeObject,
virClassForObject)))
return -1;
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Whenever we declare a new object the first member of the struct
has to be virObject (or any other member of that family). Now, up
until now we did not care about the name of the struct member.
But lets unify it so that we can do some checks at compile time
later.
The unified name is 'parent'.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
In next patches this name will be needed for a different memeber.
Also, it makes sense to rename the variable because it does not
contain reference to parent device, just its name.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Only "libxl" format supported for now. Special care needed around
vmx/svm, because those two are translated into "nestedhvm" setting.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Convert CPU features policy into libxl cpuid policy settings. Use new
("libxl") syntax, which allow to enable/disable specific bits, using
host CPU as a base. For this reason, only "host-passthrough" mode is
accepted.
Libxl do not have distinction between "force" and "required" policy
(there is only "force") and also between "forbid" and "disable" (there
is only "disable"). So, merge them appropriately. If anything, "require"
and "forbid" should be enforced outside of specific driver.
Nested HVM (vmx and svm features) is handled separately, so exclude it
from translation.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This will help with adding cpuid support.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Introduce global libxl option for enabling nested HVM feature, similar
to kvm module parameter. This will prevent enabling experimental feature
by mere presence of <cpu mode='host-passthrough'> element in domain
config, unless explicitly enabled. <cpu mode='host-passthrough'> element
may be used to configure other features, like NUMA, or CPUID.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
When support for mode=custom will be added in the future, semantics of
current config will change. Reduce the surprise by emitting a warning.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Preparation for global nestedhvm configuration - libxlMakeDomBuildInfo
needs access to libxlDriverConfig.
No functional change.
Adjusting tests require slightly more mockup functions, because of
libxlDriverConfigNew() call.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
libxlDriverConfigNew() use libxlDriverConfigDispose() for cleanup in
case of errors. Do not call libxlLoggerFree() on not allocated logger
(NULL).
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Add comma escaping for loader->path and loader->nvram.
Signed-off-by: Sukrit Bhatnagar <skrtbhtngr@gmail.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Add comma escaping for disk->vendor and disk->product when being
built for the command line (and not from hotplug).
Signed-off-by: Sukrit Bhatnagar <skrtbhtngr@gmail.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The vmware driver wants to execute vmware-vmx from the same directory in
which vmrun was found. However, on VMware Fusion 10 vmrun at
/Applications/VMware Fusion.app/Contents/Public/vmrun is a symlink
pointing to ../Library/vmrun. vmware-vmx cannot be found, as
it is not in PATH, but only in this Library directory.
Therefore, follow the vmrun symlink and use the resulting path. Then the
assumption that vmware-vmx is right next to it will still work.
Signed-off-by: Rainer Müller <raimue@codingfarm.de>
In order to not affect running VMs, refreshing the halted state
is only performed if QEMU supports the query-cpus-fast QAPI.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Extract architecture specific data from query-cpus[-fast] if
available. A new function qemuMonitorJSONExtractCPUArchInfo()
can then call architecture-specific extraction handlers.
Initially, there's a handler for s390 cpu info to
set the halted property depending on the s390 cpu state
returned by QEMU. With this it's still possible to report
the halted condition even when using query-cpus-fast.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Use query-cpus-fast instead of query-cpus if supported by QEMU.
Based on the QEMU_CAPS_QUERY_CPUS_FAST capability.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Detect whether QEMU supports the QMP query-cpus-fast API
and set QEMU_CAPS_QUERY_CPUS_FAST in this case.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
If QEMU uses a seccomp blacklist (since 2.11), -sandbox on
no longer tries to whitelist all the calls, but uses sets
of blacklists:
default (always blacklisted with -sandbox on)
obsolete (defaults to deny)
elevateprivileges (setuid & co, default: allow)
spawn (fork & execve, default: allow)
resourcecontrol (setaffinity, setscheduler, default: allow)
If these are supported, default to sandbox with all four
categories blacklisted.
https://bugzilla.redhat.com/show_bug.cgi?id=1492597
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
QEMU commit 1bd6152 changed the default behavior from whitelist
to blacklist and introduced a few sets of system calls.
Use the 'elevateprivileges' parameter of -sandbox as a witness
of this change.
https://bugzilla.redhat.com/show_bug.cgi?id=1492597
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Exit early if possible to simplify the logic.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Move the building of -sandbox command line into a separate function.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
