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>
Peter Krempa [Tue, 10 Apr 2018 15:05:20 +0000 (17:05 +0200)]
conf: Disk 'shared' state is not guest ABI
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.
Peter Krempa [Tue, 10 Apr 2018 14:57:22 +0000 (16:57 +0200)]
conf: Move 'driverName' back to disk definition structure
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.
Peter Krempa [Tue, 10 Apr 2018 14:51:47 +0000 (16:51 +0200)]
conf, qemu: Replace access to disk driver name with accessors
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.
Peter Krempa [Tue, 10 Apr 2018 14:38:22 +0000 (16:38 +0200)]
qemu: Move disk driver name validation into disk validation callback
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.
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>
Michal Privoznik [Fri, 13 Apr 2018 14:41:17 +0000 (16:41 +0200)]
cfg.mk: Introduce syntax-check rule to prefer VIR_CLASS_NEW
Now that we have macro that does some checks lets forbid raw
usage of virClassNew() in favor of VIR_CLASS_NEW().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Michal Privoznik [Tue, 17 Apr 2018 15:52:03 +0000 (17:52 +0200)]
virobject: Check if @parent is the first member in class
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>
Michal Privoznik [Tue, 17 Apr 2018 15:42:33 +0000 (17:42 +0200)]
virobject: Introduce VIR_CLASS_NEW() macro
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>
Michal Privoznik [Fri, 13 Apr 2018 11:51:23 +0000 (13:51 +0200)]
src: Unify virObject member name
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>
Michal Privoznik [Fri, 13 Apr 2018 11:42:16 +0000 (13:42 +0200)]
datatypes: Rename @parent to @parentName in virNodeDevice
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>
Michal Privoznik [Wed, 18 Apr 2018 07:37:09 +0000 (09:37 +0200)]
virmocklibxl.c: Fix include of virfile.h
Firstly, this isn't supposed to be in angle brackets because it's
not a system header file (not that gcc distinguishes these two,
it's just guide for us developers).
Secondly, no need to use util/ path prefix because CFLAGS already
contain -I$(srcdir)/util.
The include is needed because virmocklibxl is mocking
virFileMakePath() and even when VIR_MOCK_IMPL_RET_ARGS() does
forward declaration to shut up compiler we need real
virFileMakePath() declaration so that when it changes compiler
catches mismatching declarations.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
tests: add test case for CPUID in xenconfig driver
Check conversion of "cpuid" setting, check all supported policy settings
("1", "0", "x"). Also, check interaction with "nestedhvm" - should not
be included as "vmx=1" in "cpuid" setting.
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>
tests: check CPU features handling in libxl driver
Test enabling/disabling individual CPU features and also setting
nested HVM support, which is also controlled by CPU features node.
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>
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>
libxl: do not enable nested HVM unless global nested_hvm option enabled
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>
libxl: pass driver config to libxlMakeDomBuildInfo
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>
libxl: fix libxlDriverConfigDispose for partially constructed object
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>
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.
qemu: refresh vcpu halted state only via query-cpus-fast
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>
qemu: add capability detection for query-cpus-fast
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 one of the virStorageVolLookupBy{Key|Name|Path} succeeds and
we have a @vol, then clear the last libvirt error; otherwise, a
subsequent "other" failure may cause vshReportError to erroneously
report the wrong error as well as a reported 'vshError' error that
caused the failure.
Ján Tomko [Sat, 31 Mar 2018 20:15:03 +0000 (22:15 +0200)]
qemu: deny privilege elevation and spawn in seccomp
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.
Ján Tomko [Tue, 17 Apr 2018 10:11:17 +0000 (12:11 +0200)]
tests: mock qemuInterfaceOpenVhostNet
This functions contains logic that tries to use vhost for virtio
interfaces, even if <driver name='vhost'/> was not supplied.
In this case, a failure is non-fatal.
On my system, /dev/vhost-net was not accessible to the user running
'make check', but we should not depend on that.
Mock it to prevent accessing /dev/vhost-net and return some predictable
file descriptor numbers instead.
Introduced by commit c1f684e - deprecate QEMU_CAPS_VHOST_NET.
Signed-off-by: Ján Tomko <jtomko@redhat.com> Reported-by: Jiří Denemark <jdenemar@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Due to conditional execution of virTestRun(), the testCounter was incremented
only if all the cases were run. When using VIR_TEST_RANGE=x-y, first x/2 of the
increments were skipped and that made figuring out a precise case a PITA.
Moving the condition into the test function makes it way nicer to find out the
test numbers to use in VIR_TEST_RANGE.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Jiri Denemark [Wed, 21 Mar 2018 13:57:44 +0000 (14:57 +0100)]
qemu: Don't delete TLS objects unless TLS migration was requested
Trying to delete the non-existent TLS objects results in ugly error
messages in the log, which could easily confuse users. Let's avoid this
confusion by not trying to delete the objects if we were not asked to
enable TLS migration and thus we didn't created the objects anyway.
This patch restores the behavior to the state before "qemu: Reset all
migration parameters".
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Wed, 21 Mar 2018 13:22:45 +0000 (14:22 +0100)]
qemu: Drop priv->job.postcopyEnabled bool
We store the flags passed to the API which started the migration. Let's
use them instead of a separate bool to check if post-copy migration was
requested.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
We store the flags passed to the API which started QEMU_ASYNC_JOB_DUMP
and we can use them to check whether a memory-only dump is running.
There's no need for a specific bool flag.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
migrate_cancel QMP command cannot be used for cancelling memory-only
dumps and priv->job.dump_memory_only is used for reporting an error if
someone calls virDomainAbortJob when memory-only dump job is running.
Since commit 150930e3098 the dump_memory_only flag is set only if
dump-guest-memory command was called without the detach parameter. This
would incorrectly allow libvirt to send migrate_cancel while the
detached memory-only dump is running.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Wed, 21 Mar 2018 12:01:59 +0000 (13:01 +0100)]
qemu: Store API flags for async jobs in qemuDomainJobObj
When an async job is running, we sometimes need to know how it was
started to distinguish between several types of the job, e.g., post-copy
vs. normal migration. So far we added a specific bool item to
qemuDomainJobObj for such cases, which doesn't scale very well and
storing such bools in status XML would be painful so we didn't do it.
A better approach is to store the flags passed to the API which started
the async job, which can be easily stored in status XML.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Mon, 19 Mar 2018 22:45:51 +0000 (23:45 +0100)]
tests: Add tests for QEMU migration parameters
This is an enhanced replacement for the original test from
qemumonitorjsontest which was dropped earlier in this series. More data
files with some real data will be added in the following patches.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Tue, 13 Mar 2018 15:08:49 +0000 (16:08 +0100)]
qemu: Properly reset migration params when libvirtd restarts
To be able to restore all migration parameters when libvirtd is
restarting during an active migration job, we need to store the original
values of all parameters (stored in priv->job.migParams) in the status
XML.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Fri, 16 Mar 2018 12:05:08 +0000 (13:05 +0100)]
qemu: Set migration parameters automatically
Most QEMU migration parameters directly correspond to
VIR_MIGRATE_PARAM_* typed parameters and qemuMigrationParamsFromFlags
can automatically set them according to a static mapping between libvirt
and QEMU parameters.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu: Check remote caps when enabling always-on capabilities
When an always-on migration capability is supposed to be enabled on both
sides of migration, each side can only enable the feature if it is
enabled by the other side.
Thus the source host sends a list of supported migration capabilities in
the migration cookie generated in the Begin phase. The destination host
consumes the list in the Prepare phase and decides what capabilities can
be enabled when starting a QEMU process for incoming migration. Once
done the destination sends the list of supported capabilities back to
the source where it is used during the Perform phase to determine what
capabilities can be automatically enabled.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu: Add support for sending capabilities in migration cookie
Some migration capabilities may be enabled automatically, but only if
both sides of migration support them. Thus we need to be able transfer
the list of supported migration capabilities in migration cookie.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since the monitor code no longer needs to see this enum, we move it
to the place where migration parameters are defined and drop the
"monitor" reference from the name.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
We want to have all migration capabilities parsing and formatting at one
place, i.e., in qemu_migration_params.c. The parsing is already there in
qemuMigrationCapsCheck.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Wed, 28 Mar 2018 16:25:58 +0000 (18:25 +0200)]
qemu: Refactor qemuMigrationParams
Adding support for new migration parameter requires a lot of places to
be changed (most likely by copy&paste engineering): new variables to
store the parameter value and the associated *_set bool, JSON formatter
and parser, XML formatter and parser (to be added soon), and the actual
code to set the parameter. It's pretty easy to forget about some of the
places which need to be updated and end up with incorrect support. The
goal of this patch is to let most of the places do their job without any
modifications when new parameters are added.
To achieve the goal, a new qemuMigrationParam enum is introduced and all
parameters are stored in an array indexed by the items of this enum.
This will also allow us to automatically set the migration parameters
which directly correspond to libvirt's typed parameters accepted by
virDomainMigrate* APIs.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Thu, 15 Mar 2018 10:50:36 +0000 (11:50 +0100)]
qemumonitorjsontest: Drop migration params test
The test is mostly useless and we want to refactor migration parameters
even further. The refactoring will allow us to introduce enhanced tests
for migration parameters.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Fri, 9 Mar 2018 16:30:16 +0000 (17:30 +0100)]
qemu: Drop qemuMigrationCompression structure
By merging qemuMigrationAnyCompressionParse into
qemuMigrationParamsSetCompression we can drop the useless intermediate
qemuMigrationCompression structure and parse compression related typed
parameters and flags directly into qemuMigrationParams.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
projects / libvirt.git / log