A recent adjustment to qemuDomainAttachRNGDevice to properly cleanup
the props object after a qemuMonitorAddObject also would affect this
code. Alter the cleanup to be similar to RNG changes.
Based on recent review comment - rather than have a spate of goto failxxxx,
change to a boolean based model. Ensures that the original error can be
preserved and cleanup is a bit more orderly if more objects are added.
Based on recent review comment - rather than have a spate of goto failxxxx,
change to a boolean based model. Ensures that the original error can be
preserved and cleanup is a bit more orderly if more objects are added.
Based on recent review comment - rather than have a spate of goto failxxxx,
change to a boolean based model. Ensures that the original error can be
preserved and cleanup is a bit more orderly if more objects are added.
Based on recent review comment - rather than have a spate of goto failxxxx,
change to a boolean based model. Ensures that the original error can be
preserved and cleanup is a bit more orderly if more objects are added.
Based on recent review comment - rather than have a spate of goto failxxxx,
change to a boolean based model. Ensures that the original error can be
preserved and cleanup is a bit more orderly if more objects are added.
Older libvirt versions send persistent XML in a migration cookie even
when VIR_MIGRATE_PERSIST_DEST flag is not used, but current libvirt
properly fails if the cookie contains unexpected flags. Thus migration
from old libvirt fails with
internal error: Unsupported migration cookie feature persistent
unless VIR_MIGRATE_PERSIST_DEST flag is set.
https://bugzilla.redhat.com/show_bug.cgi?id=1320500
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
In preparation to tracking which USB addresses are occupied.
Introduce two helper functions for printing the port path
as a string and appending it to a virBuffer.
We were requiring a USB port path in the schema, but not enforcing it.
Omitting the USB port would lead to libvirt formatting it as (null).
Such domain cannot be started and will disappear after libvirtd restart
(since it cannot parse back the XML).
Only format the port if it has been specified and mark it as optional
in the XML schema.
Migration to an older libvirt (pre v1.3.0-175-g7140807) is broken
because older versions of libvirt generated different channel paths and
they didn't drop the default paths when parsing domain XMLs. We'd get
such a nice error message:
internal error: process exited while connecting to monitor:
2016-07-08T15:28:02.665706Z qemu-kvm: -chardev socket,
id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/
domain-3-nest/org.qemu.guest_agent.0,server,nowait: Failed to bind
socket to /var/lib/libvirt/qemu/channel/target/domain-3-nest/
org.qemu.guest_agent.0: No such file or directory
That said, we should not even format the default paths when generating a
migratable XML.
https://bugzilla.redhat.com/show_bug.cgi?id=1320470
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Playing directly with our live definition, updating it, and reverting it
back once we are done is very nice and it's quite dangerous too. Let's
just make a copy of the domain definition if needed and do all tricks on
the copy.
https://bugzilla.redhat.com/show_bug.cgi?id=1320470
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1354238
So we spend some time and effort constructing perfect file name
for an automatic coredump of a domain, but then just leak it and
use the domain name anyway. This is probably due to a silly
mistake that slipped even through review.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Check whether QEMU supports -device intel-iommu
Note that the presence of this option does not mean that it's
usable because of a bug in earlier QEMU versions, but it's
better than nothing.
https://bugzilla.redhat.com/show_bug.cgi?id=1235580
This one's a bit more complicated. In qemuProcessPrepareDomain()
a master key for encrypting secret for ciphered disks is created.
This object lives within qemuDomainObjPrivate object. It is freed
in qemuProcessStop(), but if nobody calls it (for instance like
our qemuxml2argvtest does), the key object leaks.
==17078== 32 bytes in 1 blocks are definitely lost in loss record 633 of 707
==17078== at 0x4C2C070: calloc (vg_replace_malloc.c:623)
==17078== by 0xAD924DF: virAllocN (viralloc.c:191)
==17078== by 0x5050BA6: virCryptoGenerateRandom (qemuxml2argvmock.c:166)
==17078== by 0x453DC8: qemuDomainMasterKeyCreate (qemu_domain.c:678)
==17078== by 0x47A36B: qemuProcessPrepareDomain (qemu_process.c:4913)
==17078== by 0x47C728: qemuProcessCreatePretendCmd (qemu_process.c:5542)
==17078== by 0x433698: testCompareXMLToArgvFiles (qemuxml2argvtest.c:332)
==17078== by 0x4339AC: testCompareXMLToArgvHelper (qemuxml2argvtest.c:413)
==17078== by 0x446E7A: virTestRun (testutils.c:179)
==17078== by 0x445BD9: mymain (qemuxml2argvtest.c:2022)
==17078== by 0x44886F: virTestMain (testutils.c:969)
==17078== by 0x445D9B: main (qemuxml2argvtest.c:2036)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Just like every other qemuBuild*CommandLine() function, this uses
a buffer to hold partial cmd line strings too. However, if
there's an error, the control jumps to 'cleanup' label leaving
the buffer behind and thus leaking it.
==2013== 1,006 bytes in 1 blocks are definitely lost in loss record 701 of 711
==2013== at 0x4C29F80: malloc (vg_replace_malloc.c:296)
==2013== by 0x4C2C32F: realloc (vg_replace_malloc.c:692)
==2013== by 0xAD925A8: virReallocN (viralloc.c:245)
==2013== by 0xAD95EA8: virBufferGrow (virbuffer.c:130)
==2013== by 0xAD95F78: virBufferAdd (virbuffer.c:165)
==2013== by 0x5097F5: qemuBuildCpuModelArgStr (qemu_command.c:6339)
==2013== by 0x509CC3: qemuBuildCpuCommandLine (qemu_command.c:6437)
==2013== by 0x51142C: qemuBuildCommandLine (qemu_command.c:9174)
==2013== by 0x47CA3A: qemuProcessCreatePretendCmd (qemu_process.c:5546)
==2013== by 0x433698: testCompareXMLToArgvFiles (qemuxml2argvtest.c:332)
==2013== by 0x4339AC: testCompareXMLToArgvHelper (qemuxml2argvtest.c:413)
==2013== by 0x446E7A: virTestRun (testutils.c:179)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Setting up cgroups and other things for all kinds of threads (the
emulator thread, vCPU threads, I/O threads) was copy-pasted every time
new thing was added. Over time each one of those functions changed a
bit differently. So create one function that does all that setup and
start using it, starting with I/O thread setup. That will shave some
duplicated code and maybe fix some bugs as well.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
The code in qemuDomainObjPrivateXMLParseVcpu for parsing
the 'idstr' string was comparing the overall boolean
result against 0 which was always true
qemu/qemu_domain.c: In function 'qemuDomainObjPrivateXMLParseVcpu':
qemu/qemu_domain.c:1482:59: error: comparison of constant '0' with boolean expression is always false [-Werror=bool-compare]
if ((idstr && virStrToLong_uip(idstr, NULL, 10, &idx)) < 0 ||
^
It was further performing two distinct error checks in
the same conditional and reporting a single error message,
which was misleading in one of the two cases.
This splits the conditional check into two parts with
distinct error messages and fixes the logic error.
Fixes the bug in
commit 5184f398b4
Author: Peter Krempa <pkrempa@redhat.com>
Date: Fri Jul 1 14:56:14 2016 +0200
qemu: Store vCPU thread ids in vcpu private data objects
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
An error in virHostCPUGetKVMMaxVCPUs() means we've been unable
to access /dev/kvm, or we're running on a platform that doesn't
support KVM in the first place.
If that's the case, we shouldn't ignore the error and report
domcapabilities even though we know the user won't be able to
start any KVM guest.
Allow to store driver specific data on a per-vcpu basis.
Move of the virDomainDef*Vcpus* functions was necessary as
virDomainXMLOptionPtr was declared below this block and I didn't want to
split the function headers.
Most callers make sure that it's never called with an out of range vCPU.
Every other caller reports a different error explicitly. Drop the error
reporting and clean up some dead code paths.
Otherwise migration during which we didn't send client_migrate_info QMP
command will get stuck waiting for SPICE migration to finish if libvirtd
sent the QMP command in a previous migration attempt.
Broken by bd7c8a69.
https://bugzilla.redhat.com/show_bug.cgi?id=1151723
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
This is preferrable to -nographic which (in addition to disabling
graphics output) redirects the serial port to stdio and on OpenBIOS
enables the firmware's serial console.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Due to the way the hardware works, KVM on ppc64 always requires
memory locking; however, that is not the case for non-KVM ppc64
guests, eg. ppc64 guests that are running on x86_64 with TCG.
Only require memory locking for ppc64 guests if they are using
KVM or, as it's the case for all architectures, they have host
devices assigned using VFIO.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1350772
For type='ethernet' interfaces only.
(This patch had been pushed earlier in
commit 0b4645a7e0, but was reverted in
commit 84d47a3cce because it had been
accidentally pushed during the freeze for release 2.0.0)
Introduce a helper to help determine if a disk src could be possibly used
for a disk secret... Going to need this for hot unplug.
Signed-off-by: John Ferlan <jferlan@redhat.com>
In order to use more common code and set up for a future type, modify the
encryption secret to allow the "usage" attribute or the "uuid" attribute
to define the secret. The "usage" in the case of a volume secret would be
the path to the volume as dictated by the backwards compatibility brought
on by virStorageGenerateQcowEncryption where it set up the usage field as
the vol->target.path and didn't allow someone to provide it. This carries
into virSecretObjListFindByUsageLocked which takes the secret usage attribute
value from from the domain disk definition and compares it against the
usage type from the secret definition. Since none of the code dealing
with qcow/qcow2 encryption secrets uses usage for lookup, it's a mostly
cosmetic change. The real usage comes in a future path where the encryption
is expanded to be a luks volume and the secret will allow definition of
the usage field.
This code will make use of the virSecretLookup{Parse|Format}Secret common code.
Signed-off-by: John Ferlan <jferlan@redhat.com>
I'm not sure why our code claimed "-boot menu=on" cannot be used in
combination with per-device bootindex, but it was proved wrong about
four years ago by commit 8c952908. Let's always use bootindex when QEMU
supports it.
https://bugzilla.redhat.com/show_bug.cgi?id=1323085
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Some code paths already assume that it is allocated since it was always
allocated by virDomainPerfDefParseXML. Make it member of virDomainDef
directly so that we don't have to allocate it all the time.
This fixes crash when attempting to connect to an existing process via
virDomainQemuAttach since we would not allocate it in that code path.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1350688
Ensure that the given controller and all controllers with a smaller
index exist; there must not be any missing index in between.
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
The commit "qemu: hot-plug: Assume support for -device in
qemuDomainAttachSCSIDisk" dropped the code for the automatic SCSI
controller creation used in SCSI disk hot-plugging. If we are
hot-plugging a SCSI disk to a domain and there is no proper SCSI
controller defined, it results in an "error: internal error: Could not
find scsi controller with index X required for device" error.
For that reason reverting a hunk of the commit
d4d32005d6.
This patch also adds an extra comment to the code to clarify the
loop.
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
CVE-2016-5008
Setting an empty graphics password is documented as a way to disable
VNC/SPICE access, but QEMU does not always behaves like that. VNC would
happily accept the empty password. Let's enforce the behavior by setting
password expiration to "now".
https://bugzilla.redhat.com/show_bug.cgi?id=1180092
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
libvirt's qemu driver doesn't have direct access to the config on the
guest side of a network interface, and currently doesn't have any
method in place to even inform the guest of the desired config. In the
future, an unenforceable attempt to set the guest-side IP info could
be made by adding a static host entry to the appropriate dnsmasq
configuration (or changing the default dhcp client address on the qemu
commandline for type='user' interfaces), or enhancing the guest agent
to allow setting an IP address, but for now it can't have any effect,
and we don't want to give the illusion that it does.
To prevent the "disappearance" of any existing configs with ip
address/route info (due to parser failure), this check is added in the
newly implemented qemuDomainDeviceDefValidate(), which is only called
when a domain is defined or started, *not* when it is reread from disk
at libvirtd startup.
When support for <interface type='ethernet'> was added in commit
9a4b705f back in 2010, it erroneously looked at <source dev='blah'/>
for a user-specified guest-side interface name. This was never
documented though. (that attribute already existed at the time in the
data.ethernet union member of virDomainNetDef, but apparently had no
practical use - it was only used as a storage place for a NetDef's
bridge name during qemuDomainXMLToNative(), but even then that was
never used for anything).
When support for similar guest-side device naming was added to the lxc
driver several years later, it was put in a new subelement <guest
dev='blah'/>.
In the intervening years, since there was no validation that
ethernet.dev was NULL in the other drivers that didn't actually use
it, innocent souls who were adding other features assuming they needed
to account for non-NULL ethernet.dev when really they didn't, so
little bits of the usual pointless cargo-cult code showed up.
This patch not only switches the openvz driver to use the documented
<guest dev='blah'/> notation for naming the guest-side device (just in
case anyone is still using the openvz driver), and logs an error if
anyone tries to set <source dev='blah'/> for a type='ethernet'
interface, it also removes the cargo-cult uses of ethernet.dev and
<source dev='blah'/>, and eliminates if from the RNG and from
virDomainNetDef.
NB: I decided on this course of action after mentioning the
inconsistency here:
https://www.redhat.com/archives/libvir-list/2016-May/msg02038.html
and getting encouragement do eliminate it in a later IRC discussion
with danpb.
in qemuConnectDomainXMLToNative. This function was only accounting for
about 1/10 of all the allocated items in the NetDef prior to memseting
it to all 0's. On top of that, it was going to great pains to learn
the name of the bridge device, but then never doing anything useful
with it (just putting it into data.ethernet.dev, which is *never* used
when building a qemu commandline). (I think this again all started off
as code with good intentions, but it was never completed, and instead
was just Frankensteinically cargo-culted into the odd mish mash we
have today).
The resulting code is much simpler, produces exactly the same output,
and doesn't leak memory.
This patch removes the expanded and duplicated code that all sprung
out of two well-intentioned-but-useless settings of
net->data.(bridge|ethernet).ipaddr.
qemu has never supported even a single IP address in the interface
config, much less a list of them. All of the instances of "clearing
out the IP addresses" that are now in this function originated with
commit d8dbd6 "Basic domain XML conversions for Xen/QEMU drivers" in
May 2009, but even then the single "ipaddr" in the struct for
type='ethernet' and type='bridge' wasn't used in the qemu driver (only
in xen and openvz). Since then anyone who added a new interface type
also tacked on another unnecessary clearing of ipaddr, and when it was
made into a list of IPs (so far supported only by the LXC driver) this
simple setting was turned into a loop (well, multiple loops) to clear
them all.
I'm tired of mistyping this all the time, so let's do it the same all
the time (similar to how we changed all "Pci" to "PCI" awhile back).
(NB: I've left alone some things in the esx and vbox drivers because
I'm unable to compile them and they weren't obviously *not* a part of
some API. I also didn't change a couple of variables named,
e.g. "somethingIptables", because they were derived from the name of
the "iptables" command)
Rather than pass authdef, pass the 'authdef->username' and the
'&authdef->secdef'
Note that a username may be NULL.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Rather than assume/pass the protocol to the qemuDomainSecretPlainSetup
and qemuDomainSecretAESSetup, set and pass the secretUsageType based
on the src->protocol type. This will eventually be used by the
virSecretGetSecretString call
Signed-off-by: John Ferlan <jferlan@redhat.com>
This kvmGetMaxVCPUs() needs to be used at two different places
so move it to utils with appropriate name and mark it as private
global now.
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
On PPC the legacy passthrough is not supported and only
VFIO is supported. So, the checks at places to confirm if the
host is passthrough capable checks only legacy, fix it. This
is seen at only one place now.
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Unfortunately, we can't just call qemuDomainMachineIsPSeries()
here, because we don't have a virDomainDef instance; that said,
the open-coded check should match said function as closely as
possible.
The directories we iterate over are unlikely to contain any entries
starting with a dot, other than '.' and '..' which is already skipped
by virDirRead.
Move the enum into a new src/util/virsecret.h, rename it to be
virSecretLookupType. Add a src/util/virsecret.h in order to perform
a couple of simple operations on the secret XML and virSecretLookupTypeDef
for clearing and copying.
This includes quite a bit of collateral damage, but the goal is to remove
the "virStorage*" and replace with the virSecretLookupType so that it's
easier to to add new lookups that aren't necessarily storage pool related.
Signed-off-by: John Ferlan <jferlan@redhat.com>
One can not issue monitor commands manually during async calls thru
designated API while this could be useful for testing/debugging purposes.
qemuDomainQemuMonitorCommand uses job of type QEMU_JOB_MODIFY and any async
call disable parallel execution of this type of job. The only state that is
changed is taint variable. AFAIU the only place we can mess is resetting
taint flag in qemuProcessStop routine under some async job. But this can not
happen thanx to both virDomainObjIsActive check in qemuDomainQemuMonitorCommand
and resetting active status in qemuProcessStop before taint flag.
Change job type to QEMU_JOB_QUERY and thus make the API call available for
most of async jobs.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Several places in the code update qemuMonitorMigrationParams structure
and qemuMigrationSetParams is then used to set them all at once.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
We should not require any parameters to be present. After all we have
the *_set bools to express that some parameters were not set.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
qemuMonitorMigrationParams is a better name for a structure which
contains various migration parameters. While doing that, we should use
full names for individual parameters.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Checking whether the function has anything to do is better done in the
function rather then requiring callers to do that.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Since virQEMUCapsNewForBinaryInternal was introduced,
virQEMUCapsNewForBinary is no longer used outside qemu_capabilities.c.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Allow gathering available vcpu ids, their state and offlinability via
the qemu guest agent. The maximum id was chosen arbitrarily and ought
to be enough for everybody.
Documentation for the "guest-set-vcpus" command describes a proper
algorithm how to set vcpus. This patch makes the following changes:
- state of cpus that has not changed is not updated
- if the command was partially successful the command is re-tried with
the rest of the arguments to get a proper error message
- code is more robust against malicious guest agent
- fix testsuite to the new semantics
