The return values for the virDomainGetJobStats call were not
bounds checked. This is a robustness issue for clients if
something where to cause corruption of the RPC stream data.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The parameters for the virDomainMigrate*Params RPC calls were
not bounds checks, meaning a malicious client can cause libvirtd
to consume arbitrary memory
This issue was introduced in the 1.1.0 release of libvirt
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
One of my previous patches 5cfe0d37cd tried to handle the case when
libvirt is a submodule of another project. In that case, the .git is
just a link to the parent .git directory (which the autogen.sh script
didn't count on). The fix was missing 'test' though.
Similarly to qemu_driver.c, we can join often repeating code of looking
up network into one function: networkObjFromNetwork.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
When using a <interface type="network"> that points to a network with
hostdev forwarding mode a hostdev alias is created for the network. This
allias is inserted into the hostdev list, but is backed with a part of
the network object that it is connected to.
When a VM is being stopped qemuProcessStop() calls
networkReleaseActualDevice() which eventually frees the memory for the
hostdev object. Afterwards when the domain definition is being freed by
virDomainDefFree() an invalid pointer is accessed by
virDomainHostdevDefFree() and may cause a crash of the daemon.
This patch removes the entry in the hostdev list before freeing the
depending memory to avoid this issue.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1000973
Noticed while reviewing another patch that had an accidental
mismatch due to refactoring. An audit of the code showed that
very few callers of vshCommandOpt were expecting a return of
-2, indicating programmer error, and of those that DID check,
they just propagated that status to yet another caller that
did not check. Fix this by making the code blatantly warn
the programmer, rather than silently ignoring it and possibly
doing the wrong thing downstream.
I know that we frown on assert()/abort() inside libvirtd
(libraries should NEVER kill the program that linked them),
but as virsh is an app rather than the library, and as this
is not the first use of assert() in virsh, I think this
approach is okay.
* tools/virsh.h (vshCommandOpt): Drop declaration.
* tools/virsh.c (vshCommandOpt): Make static, and add a
parameter. Abort on programmer errors rather than making callers
repeat that logic.
(vshCommandOptInt, vshCommandOptUInt, vshCommandOptUL)
(vshCommandOptString, vshCommandOptStringReq)
(vshCommandOptLongLong, vshCommandOptULongLong)
(vshCommandOptBool): Adjust callers.
Signed-off-by: Eric Blake <eblake@redhat.com>
Surprisingly, augtool get (or print) returns "path = value" while we are
only interested in the value. We need to remove the "path = " part from
the augtool's output. The following is an example of the augtool command
as used in virt-sanlock-cleanup script:
$ augtool get /files/etc/libvirt/qemu-sanlock.conf/disk_lease_dir
/files/etc/libvirt/qemu-sanlock.conf/disk_lease_dir = /var/lib/libvirt/sanlock
Commit a0b6a36f "fixed" what abfff210 broke (URI precedence), but
there was still one more thing missing to fix. When using virsh
parameters to setup debugging, those weren't honored, because at the
time debugging was initializing, arguments weren't parsed yet. To
make ewerything work as expected, we need to initialize the debugging
twice, once before debugging (so we can debug option parsing properly)
and then again after these options are parsed.
As a side effect, this patch also fixes a leak when virsh is ran with
multiple '-l' parameters.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Since 785ff34bf8 we are using the outputStr variable in cleanup label.
However, there is a possibility to jump to the label before the variable
has been declared:
virsh-pool.c: In function 'cmdPoolList':
virsh-pool.c:1121:25: error: jump skips variable initialization [-Werror=jump-misses-init]
goto asprintf_failure;
^
virsh-pool.c:1308:1: note: label 'asprintf_failure' defined here
asprintf_failure:
^
virsh-pool.c:1267:11: note: 'outputStr' declared here
char *outputStr = NULL;
VIR_FREE(caps) is not enough to free an array allocated
by vshStringToArray.
==17== 4 bytes in 1 blocks are definitely lost in loss record 4 of 728
==17== by 0x4EFFC44: virStrdup (virstring.c:554)
==17== by 0x128B10: _vshStrdup (virsh.c:125)
==17== by 0x129164: vshStringToArray (virsh.c:218)
==17== by 0x157BB3: cmdNodeListDevices (virsh-nodedev.c:409)
https://bugzilla.redhat.com/show_bug.cgi?id=1001536
==23== 41 bytes in 1 blocks are definitely lost in loss record 626 of 727
==23== by 0x4F0099F: virAsprintfInternal (virstring.c:358)
==23== by 0x15D2C9: cmdPoolList (virsh-pool.c:1268)
https://bugzilla.redhat.com/show_bug.cgi?id=1001536
virsh secret-list leak when no secrets are defined:
==27== 8 bytes in 1 blocks are definitely lost in loss record 6 of 726
==27== by 0x4E941DD: virAllocN (viralloc.c:183)
==27== by 0x5037F1A: remoteConnectListAllSecrets (remote_driver.c:3076)
==27== by 0x5004EC6: virConnectListAllSecrets (libvirt.c:16298)
==27== by 0x15F813: vshSecretListCollect (virsh-secret.c:397)
==27== by 0x15F0E1: cmdSecretList (virsh-secret.c:532)
And so do some other *-list commands.
https://bugzilla.redhat.com/show_bug.cgi?id=1001536
The messages were only freed on error.
==12== 1,100 bytes in 1 blocks are definitely lost in loss record 698 of 729
==12== by 0x4E98C22: virBufferAsprintf (virbuffer.c:294)
==12== by 0x12C950: vshOutputLogFile (virsh.c:2440)
==12== by 0x12880B: vshError (virsh.c:2254)
==12== by 0x131957: vshCommandOptDomainBy (virsh-domain.c:109)
==12== by 0x14253E: cmdStart (virsh-domain.c:3333)
https://bugzilla.redhat.com/show_bug.cgi?id=1001536
QEMU commit 3984890 introduced the "pci-hole64-size" property,
to i440FX-pcihost and q35-pcihost with a default setting of 2 GB.
Translate <pcihole64>x<pcihole64/> to:
-global q35-pcihost.pci-hole64-size=x for q35 machines and
-global i440FX-pcihost.pci-hole64-size=x for i440FX-based machines.
Error out on other machine types or if the size was specified
but the pcihost device lacks 'pci-hole64-size' property.
https://bugzilla.redhat.com/show_bug.cgi?id=990418
<controller type='pci' index='0' model='pci-root'>
<pcihole64 unit='KiB'>1048576</pcihole64>
</controller>
It can be used to adjust (or disable) the size of the 64-bit
PCI hole. The size attribute is in kilobytes (different unit
can be specified on input), but it gets rounded up to
the nearest GB by QEMU.
Disabling it will be needed for guests that crash with the
64-bit PCI hole (like Windows XP), see:
https://bugzilla.redhat.com/show_bug.cgi?id=990418
The ftp protocol is already recognized by qemu/KVM so add this support to
libvirt as well.
The xml should be as following:
<disk type='network' device='cdrom'>
<source protocol='ftp' name='/url/path'>
<host name='host.name' port='21'/>
</source>
</disk>
Signed-off-by: Aline Manera <alinefm@br.ibm.com>
QEMU/KVM already allows a HTTP URL for the cdrom ISO image so add this support
to libvirt as well.
The xml should be as following:
<disk type='network' device='cdrom'>
<source protocol='http' name='/url/path'>
<host name='host.name' port='80'/>
</source>
</disk>
Signed-off-by: Aline Manera <alinefm@br.ibm.com>
qemu-img is going to switch the default for QCOW2
to QCOW2v3 (compat=1.1)
Extend the probing for qemu-img command line options to check
if -o compat is supported. If the volume definition specifies
the qcow2 format but no compat level and -o compat is supported,
specify -o compat=0.10 to create a QCOW2v2 image.
https://bugzilla.redhat.com/show_bug.cgi?id=997977
virsh cpu-stats guest --start 0 --count 3
It outputs right but the return value is 1 rather than 0
echo $?
1
Found by running libvirt-autotest
./run -t libvirt --tests virsh_cpu_stats
If there's no hard_limit set and domain uses VFIO we still must lock
the guest memory (prerequisite from qemu). Hence, we should compute
the amount to be locked from max_balloon.
When cpu hotplug fails without reporting an error, we would fail the
command but update the count of vCPUs anyways.
Commit 761fc48136 fixed the case when CPU
hot-unplug failed silently, but forgot to fix up the value in this case.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1000357
On IRC, someone complained that a system without xmllint installed
failed a number of tests.
* tests/schematestutils.sh: Probe for xmllint.
Signed-off-by: Eric Blake <eblake@redhat.com>
Consistently use "is" or "is not" to compare variables to None,
because doing so is preferrable, as per PEP 8
(http://www.python.org/dev/peps/pep-0008/#programming-recommendations):
> Comparisons to singletons like None should always be done with is or
> is not, never the equality operators.
