More misunderstanding/mistaken assumptions on my part - I had thought
that a pci-expander-bus could be plugged into any legacy PCI slot, and
that pcie-expander-bus could be plugged into any PCIe slot. This isn't
correct - they can both be plugged ontly into their respective root
buses. This patch adds that restriction.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1358712
libvirt had allowed a dmi-to-pci-bridge to be plugged in anywhere a
normal PCIe endpoint can be connected, but this is wrong - it will
only work if it's plugged into pcie-root (the PCIe root complex) or a
pcie-expander-bus (the qemu device pxb-pcie). This patch adjusts the
connection flags accordingly.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1363648
I apparently misunderstood Marcel's description of what could and
couldn't be plugged into qemu's pxb-pcie controller (known as
pcie-expander-bus in libvirt) - I specifically allowed directly
connecting a pcie-switch-upstream-port, and it turns out that causes
the guest kernel to crash.
This patch forbids such a connection, and updates the xml docs
appropriately.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1361172
The virDomainPCIAddressFlagsCompatible() error logs report that a
device required a controller that accepted standard PCI endpoint
devices, or PCI Express endpoint devices, and if hotplug was required
by the configuration but not provided by the selected controller. But
the wording of the error messages was apparently confusing (according
to the bugzilla report referenced below). On top of that, if the
device was something other than an endpoint device (e.g. a
pcie-switch-downstream-port) the error message was a complete punt -
it would just say that the flags were incorrect.
This patch makes the messages for PCI/PCIe endpoint and hotplug
requirements more clear, and also specifically indicates what was the
device type when it is other than an endpoint device.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1363627
Since the introduction of CMT features (commit v1.3.5-461-gf294b83)
starting a domain with host-model CPU on a host which supports CMT fails
because QEMU complains about unknown 'cmt' feature:
qemu-system-x86_64: CPU feature cmt not found
https://bugzilla.redhat.com/show_bug.cgi?id=1355857
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
By removing a non-migratable feature in a for loop we would fail to drop
every second non-migratable feature if the features array contained
several of them in a row.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Commit 30ce2f0e tried to fix the issue with an incorrect session URI to admin
server but it messed up the checks:
if (geteuid == 0 && VIR_STRDUP(*uristr, "libvirtd:///system") < 0)
return -1;
else if (VIR_STRDUP(*uristr, "libvirtd:///session") < 0)
return -1;
So if a client executed with root privileges tries to connect, its euid is
checked (true) and the correct URI is successfully copied to @uristr (false),
therefore the 'else' branch is taken and @uristr is replaced by the session URI
which for root results in:
Failed to connect socket to '/root/.cache/libvirt/libvirt-admin-sock':
No such file or directory
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Just like we decide on which URI we go with based on EUID for qemu in remote
driver, do a similar thing for admin except we do not spawn a daemon in this
case.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1356858
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Commit b3e4401dc6 introduced a check to ignore an error if the guest
is already terminated. However the check accidentally compared
error.code with VIR_ERR_ERROR, which is an error level, not an error
code. Because of this, almost every error got silently ignored.
Fixes: b3e4401dc6 ("systemd: don't report an error if the guest is
already terminated")
Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: Sascha Silbe <silbe@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
When build for architecture that don't use gcc atomic ops but pthread,
it fails to build for armel:
| ../tools/nss/.libs/libnss_libvirt_impl.a(libvirt_nss_la-virobject.o): In function `virClassNew':
| /buildarea2/kkang/builds/qemuarm-Aug03/bitbake_build/tmp/work/armv5e-wrs-linux-gnueabi/libvirt/1.3.5-r0/build/src/../../libvirt-1.3.5/src/util/virobject.c:153: undefined reference to `virAtomicLock'
| ../tools/nss/.libs/libnss_libvirt_impl.a(libvirt_nss_la-virobject.o): In function `virObjectNew':
| /buildarea2/kkang/builds/qemuarm-Aug03/bitbake_build/tmp/work/armv5e-wrs-linux-gnueabi/libvirt/1.3.5-r0/build/src/../../libvirt-1.3.5/src/util/virobject.c:205: undefined reference to `virAtomicLock'
| ../tools/nss/.libs/libnss_libvirt_impl.a(libvirt_nss_la-virobject.o): In function `virObjectUnref':
| /buildarea2/kkang/builds/qemuarm-Aug03/bitbake_build/tmp/work/armv5e-wrs-linux-gnueabi/libvirt/1.3.5-r0/build/src/../../libvirt-1.3.5/src/util/virobject.c:277: undefined reference to `virAtomicLock'
| ../tools/nss/.libs/libnss_libvirt_impl.a(libvirt_nss_la-virobject.o): In function `virObjectRef':
| /buildarea2/kkang/builds/qemuarm-Aug03/bitbake_build/tmp/work/armv5e-wrs-linux-gnueabi/libvirt/1.3.5-r0/build/src/../../libvirt-1.3.5/src/util/virobject.c:298: undefined reference to `virAtomicLock'
| collect2: error: ld returned 1 exit status
It is similar with:
http://libvirt.org/git/?p=libvirt.git;a=commit;h=12dc729
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Unfortunately vz sdk do not provide detail information on migration
progress, only progress percentage. Thus vz driver provides percents
instead of bytes in data fields of virDomainJobInfoPtr.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
The build was failing with:
CCLD lockd.la
libtool: error: can't build i686-pc-cygwin shared library unless -no-undefined is specified
Rather than add yet another $(CYGWIN_EXTRA_LDFLAGS) to all the
impacted *_la_LDFLAGS, it was easier to just pull the extra
flags into ALL libraries via AM_LDFLAGS.
Then, fix lockd_la_LDFLAGS to include AM_LDFLAGS, like all other
libraries.
Signed-off-by: Eric Blake <eblake@redhat.com>
Without XDR_CFLAGS, compilation on Cygwin fails with:
CC libvirt_driver_la-libvirt-stream.lo
In file included from libvirt-stream.c:26:0:
rpc/virnetprotocol.h:9:21: fatal error: rpc/rpc.h: No such file or directory
Signed-off-by: Eric Blake <eblake@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1363773
Imagine that you're creating a transient domain, but for some reason,
starting it fails. That is virLXCProcessStart() returns an error. With
current code, in the error handling code the domain object is removed
from the domain object list, @vm is set to NULL and controls jump to
enjob label where virLXCDomainObjEndJob() is called which dereference vm
leading to instant crash.
The fix is to end the job in the error handling code and only after that
remove the domain from the list and jump onto cleanup label instead of
endjob.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1362349
When adding the ability to build the pool during the start pool processing
using the similar flags as buildPool processing would use, the code was
essentially cut-n-pasted from storagePoolCreateXML. However, that included
a call to virStoragePoolObjRemove which shouldn't happen within the
storagePoolCreate path since that'll remove the pool from the list of
pools only to be rediscovered if libvirtd restarts.
So on failure, just fail and return as we should expect
Doing a load, copy, format cycle on all QEMU capabilities XML files
should make sure we don't forget to update virQEMUCapsNewCopy when
adding new elements to QEMU capabilities.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
There was a missing check for vol->target.encryption being NULL
at one particular place (modified by commit a48c71411) which caused a crash
when user attempted to create a raw volume using a non-raw file volume as
source.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1363636
Signed-off-by: Erik Skultety <eskultet@redhat.com>
In qemu, enabling this feature boils down to adding the following
onto the command line:
-global driver=cfi.pflash01,property=secure,value=on
However, there are some constraints resulting from the
implementation. For instance, System Management Mode (SMM) is
required to be enabled, the machine type must be q35-2.4 or
later, and the guest should be x86_64. While technically it is
possible to have 32 bit guests with secure boot, some non-trivial
CPU flags tuning is required (for instance lm and nx flags must
be prohibited). Given complexity of our CPU driver, this is not
trivial. Therefore I've chosen to forbid 32 bit guests for now.
If there's ever need, we can refine the check later.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This element will control secure boot implemented by some
firmwares. If the firmware used in <loader/> does support the
feature we must tell it to the underlying hypervisor. However, we
can't know whether loader does support it or not just by looking
at the file. Therefore we have to have an attribute to the
element where users can tell us whether the firmware is secure
boot enabled or not.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Since its release of 2.4.0 qemu is able to enable System
Management Module in the firmware, or disable it. We should
expose this capability in the XML. Unfortunately, there's no good
way to determine whether the binary we are talking to supports
it. I mean, if qemu's run with real machine type, the smm
attribute can be seen in 'qom-list /machine' output. But it's not
there when qemu's run with -M none. Therefore we're stuck with
version based check.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
We use 'goto cleanup' for a reason. If a function can exit at
many places but doesn't follow the pattern, it has to copy the
free code in multiple places.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
While no leak was observed yet, there might be one if
virObjectEventClass is ever derived from another class. Because
in that case plain VIR_FREE() will not call dispose() from parent
classes possibly leaking some memory.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
In the cleanup path, @vm cannot be possibly NULL. If it were so,
we would receive SIGSEGV much earlier. At the beginning of the
function we do libxlDomainObjBeginJob(.., vm, ..); and so on.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The virJSONValueArraySize() function return ssize_t (with
possibly returning -1 if the passed json is not an array).
Storing the return value into size_t is possibly dangerous then.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Call the vcpu thread info validation separately to decrease complexity
of returned values by qemuDomainRefreshVcpuInfo.
This function now returns 0 on success and -1 on error. Certain
failures of qemu to report data are still considered as success. Any
error reported now is fatal.
Validate the presence of the thread id according to state of the vCPU
rather than just checking the vCPU count. Additionally put the new
validation code into a separate function so that the information
retrieval can be split from the validation.
Long, long ago before libxl_get_required_shadow_memory() was
made publicly available, its code was copied to the libxl driver
for calculating shadow memory requirements of HVM domains.
Long ago, libxl_get_required_shadow_memory() was exported in
libxl_utils.h and included in xen-devel packages everywhere.
Remove the copied code, which has become stale, and let libxl
provode a proper shadow memory value.
https://bugzilla.redhat.com/show_bug.cgi?id=1356937
Add support for IOThread quota/bandwidth and period parameters for non
session mode. If in session mode, then error out. Uses all the same
places where {vcpu|emulator|global}_{period|quota} are adjusted and
adds the iothread values.
https://bugzilla.redhat.com/show_bug.cgi?id=1356937
Add the definitions to allow for viewing/setting cgroup period and quota
limits for IOThreads.
This is similar to the work done for emulator quota and period by
commit ids 'b65dafa' and 'e051c482'.
Being able to view/set the IOThread specific values is related to more
recent changes adding global period (commmit id '4d92d58f') and global
quota (commit id '55ecdae') definitions and qemu support (commit id
'4e17ff79' and 'fbcbd1b2'). With a global setting though, if somehow
the IOThread value in the cgroup hierarchy was set "outside of libvirt"
to a value that is incompatible with the global value.
Allowing control over IOThread specific values provides the capability
to alter the IOThread values as necessary.
If you invoke virDomainLxcEnterSecurityLabel() on security
model of "none" it will report an error. Logically a "none"
security model should be treated as a no-op, so we should
just return success immediately, instead of an error.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1289391
Rather than pass the whole drive string (which contained the alias),
pass only the alias for the qemuMonitorDriveDel call in the error
path when adding a host device in the monitor fails.
