- 28 9月, 2017 5 次提交
-
-
由 Ashish Mittal 提交于
Add an optional virTristateBool haveTLS to virStorageSource to manage whether a storage source will be using TLS. Sample XML for a VxHS disk: <disk type='network' device='disk'> <driver name='qemu' type='raw' cache='none'/> <source protocol='vxhs' name='eb90327c-8302-4725-9e1b-4e85ed4dc251' tls='yes'> <host name='192.168.0.1' port='9999'/> </source> <target dev='vda' bus='virtio'/> </disk> Additionally add a tlsFromConfig boolean to control whether the TLS setting was due to domain configuration or qemu.conf global setting in order to decide whether to Format the haveTLS setting for either a live or saved domain configuration file. Update the qemuxml2xmltest in order to add a test to show the proper parsing. Also update the docs to describe the tls attribute. Signed-off-by: NAshish Mittal <Ashish.Mittal@veritas.com> Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Clean up the description a bit to make it more readable and not appear as one long run-on paragraph.
-
由 Ashish Mittal 提交于
Add a new TLS X.509 certificate type - "vxhs". This will handle the creation of a TLS certificate capability for properly configured VxHS network block device clients. The following describes the behavior of TLS for VxHS block device: (1) Two new options have been added in /etc/libvirt/qemu.conf to control TLS behavior with VxHS block devices "vxhs_tls" and "vxhs_tls_x509_cert_dir". (2) Setting "vxhs_tls=1" in /etc/libvirt/qemu.conf will enable TLS for VxHS block devices. (3) "vxhs_tls_x509_cert_dir" can be set to the full path where the TLS CA certificate and the client certificate and keys are saved. If this value is missing, the "default_tls_x509_cert_dir" will be used instead. If the environment is not configured properly the authentication to the VxHS server will fail. Signed-off-by: NAshish Mittal <Ashish.Mittal@veritas.com> Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
The virNWFilterIPAddrMapAddIPAddr code can consume the @addr parameter on success when the @ifname is found in the ipAddressMap->hashTable hash table in the call to virNWFilterVarValueAddValue; however, if not found in the hash table, then @addr is formatted into a @val which is stored in the table and on return the caller would be expected to free @addr. Thus, the caller has no way to determine on success whether @addr was consumed, so in order to fix this create a @tmp variable which will be stored/consumed when virNWFilterVarValueAddValue succeeds. That way the caller can free @addr whether the function returns success or failure.
-
由 Pavel Hrdina 提交于
The packet with passed FD has the following format: -------------------------- | len | header | payload | -------------------------- where "payload" has an additional count of FDs before the actual data: ------------------ | nfds | payload | ------------------ When the packet is received we parse the "header", which as a side effect updates msg->bufferOffset to point to the beginning of "payload". If the message call contains FDs, we need to also parse the count of FDs, which also updates the msg->bufferOffset. The issue here is that when we attempt to read the FDs data from the socket and we receive EAGAIN we finish the reading and call poll() to wait for the data the we need. When the data arrives we already have the packet in our buffer so we read the "header" again but this time we don't read the count of FDs because we already have it stored. That means that the msg->bufferOffset is not updated to point to the actual beginning of the payload data, but it points to the count of FDs. After all FDs are processed we dispatch the message to process it and decode the payload. Since the msg->bufferOffset points to wrong data, we decode the wrong payload and the API call fails with error messages: Domain not found: no domain with matching uuid '67656e65-7269-6300-0c87-5003ca6941f2' () Broken by commit 133c511b which fixed a FD and memory leak. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 27 9月, 2017 12 次提交
-
-
由 Peter Krempa 提交于
VM private data is cleared when the VM is turned off and also when the VM object is being freed. Some of the clearing code was duplicated. Extract it to a separate function. This also removes the now unnecessary function qemuDomainClearPrivatePaths.
-
由 Erik Skultety 提交于
Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Ján Tomko 提交于
Calling fallocate on the new (smaller) capacity ensures that the whole file is allocated, but it does not reduce the file size. Also call ftruncate after fallocate. https://bugzilla.redhat.com/show_bug.cgi?id=1366446
-
由 Ján Tomko 提交于
We have been trying to implement the ALLOCATE flag to mean "the volume should be fully allocated after the resize". Since commit b0579ed9 we do not allocate from the existing capacity, but from the existing allocation value. However this value is a total of all the allocated bytes, not an offset. For a sparsely allocated file: $ perl -e 'print "x"x8192;' > vol1 $ fallocate -p -o 0 -l 4096 vol1 $ virsh vol-info vol1 default Capacity: 8.00 KiB Allocation: 4.00 KiB Treating allocation as an offset would result in an incompletely allocated file: $ virsh vol-resize vol1 --pool default 16384 --allocate Capacity: 16.00 KiB Allocation: 12.00 KiB Call fallocate from zero on the whole requested capacity to fully allocate the file. After that, the volume is fully allocated after the resize: $ virsh vol-resize vol1 --pool default 16384 --allocate $ virsh vol-info vol1 default Capacity: 16.00 KiB Allocation: 16.00 KiB
-
由 Ján Tomko 提交于
Introduce a new function virFileAllocate that will call the non-destructive variants of safezero, essentially reverting my commit 1390c268 safezero: fall back to writing zeroes even when resizing back to the state as of commit 18f03166 virstoragefile: Have virStorageFileResize use safezero This means that _ALLOCATE flag will no longer work on platforms without the allocate syscalls, but it will not overwrite data either.
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1476775 For the virsh pool-{define|create}-as command, let's allow using --secret-uuid on the command line as an alternative to --secret-usage (added for commit id '89325806'), but ensure that they are mutually exclusive.
-
由 ZhiPeng Lu 提交于
Don't leak @inetaddr within the done: processing when attempting to instantiate the filter. Signed-off-by: NZhiPeng Lu <lu.zhipeng@zte.com.cn>
-
由 ZhiPeng Lu 提交于
If virNWFilterHashTablePut fails, then the @val was leaked. Signed-off-by: NZhiPeng Lu <lu.zhipeng@zte.com.cn>
-
由 Ján Tomko 提交于
Use an empty string to let qemu fill out the default. This matches what's done in qemuBuildChrChardevStr. https://bugzilla.redhat.com/show_bug.cgi?id=1454671Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Pavel Hrdina 提交于
This reverts commit edaf4ebe. This uses "reconnect" as attribute for <source> element, but we already have a <reconnect> element for <source> element for chardev devices. Since this is the same feature for different device it should be presented in XML the same way. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Peter Krempa 提交于
Some values we read from the qemu monitor may be changed with the actual state by the incoming migration. This means that we should refresh certain things only after the migration has finished. This is mostly visible in the cdrom tray state, which is by default closed but may be opened by the guest OS. This would be refreshed before qemu transferred the actual state and thus libvirt would think that the tray is closed. Note that this patch moves only a few obvious query commands. Others may be moved later after individual assessment. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1463168
-
由 Peter Krempa 提交于
When the vcpu is successfully removed libvirt would remove the cgroup. In cases when removal of the cgroup fails libvirt would report an error. This does not make much sense, since the vcpu was removed and we can't really do anything with the cgroup. This patch silences the errors from cgroup removal. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1462092
-
- 26 9月, 2017 3 次提交
-
-
由 Peter Krempa 提交于
-
由 Ján Tomko 提交于
It is possible (although possibly not very useful) to leave out the service attribute when using <source mode='bind'/> Fix the formatter bug introduced by commit 4a0da345 and format the host when its present (checked for non-NULL inside virBufferEscapeString) instead of basing it on the presence of the service attribute. https://bugzilla.redhat.com/show_bug.cgi?id=1455825
- 25 9月, 2017 4 次提交
-
-
由 Peter Krempa 提交于
The alias recorded in disk->info.alias is the alias for the frontend device but we are interested in the backend drive. This messed up the disk node name extraction code as qemu reports the drive alias in the block query commands. This was broken in the node name detector refactoring done in commit 0175dc6e Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1494327
-
由 Peter Krempa 提交于
Move the check that skips node name detection if they are already present earlier so that the hash table lookup is skipped.
-
由 Daniel P. Berrange 提交于
Seeing a log message saying 'flags=93' is ambiguous & confusing unless you happen to know that libvirt always prints flags as hex. Change our debug messages so that they always add a '0x' prefix when printing flags, and '0' prefix when printing mode. A few other misc places gain a '0x' prefix in error messages too. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Jim Fehlig 提交于
Kernel 4.13 introduced finer-grained ptrace checks https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=v4.13.2&id=290f458a4f16f9cf6cb6562b249e69fe1c3c3a07 With kernel 4.13 and apparmor 2.11, simply starting libvirtd results in the following apparmor denial type=AVC msg=audit(1506112085.645:954): apparmor="DENIED" operation="ptrace" profile="/usr/sbin/libvirtd" pid=6984 comm="libvirtd" requested_mask="trace" denied_mask="trace" peer="unconfined" Attempting to start an unconfined domain results in type=AVC msg=audit(1506112301.227:1112): apparmor="DENIED" operation="ptrace" profile="/usr/sbin/libvirtd" pid=7498 comm="libvirtd" requested_mask="trace" denied_mask="trace" peer="/usr/sbin/libvirtd" And attempting to start a confined domain results in type=AVC msg=audit(1506112631.408:1312): apparmor="DENIED" operation="open" profile="virt-aa-helper" name="/etc/libnl/classid" pid=8283 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 type=AVC msg=audit(1506112631.530:1319): apparmor="DENIED" operation="open" profile="virt-aa-helper" name="/etc/libnl/classid" pid=8289 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 type=AVC msg=audit(1506112632.186:1324): apparmor="DENIED" operation="ptrace" profile="/usr/sbin/libvirtd" pid=8342 comm="libvirtd" requested_mask="trace" denied_mask="trace" peer="libvirt-66154842-e926-4f92-92f0-1c1bf61dd1ff" Add ptrace rules to allow the trace operations. Resolves: https://bugzilla.suse.com/show_bug.cgi?id=1058847Signed-off-by: NJim Fehlig <jfehlig@suse.com> Reviewed-by: NGuido Günther <agx@sigxcpu.org>
-
- 22 9月, 2017 12 次提交
-
-
由 Ján Tomko 提交于
The functionality was added in 4.8, but due to a rename of the DEVLINK_CMD_ESWITCH_GET constant in the kernel headers, the headers from kernel 4.11 are required by the libvirt code. Remove the reference from the news entry, since it could be misleading.
-
由 Peter Krempa 提交于
Some distros (see diff) chose to backport QMP support rather than rebase to newer version of qemu. As a hack they added the string 'libvirt' to the qemu -help output. Remove this as downstream-only hacks should be carried by downstream and not litter upstream. This effectively reverts commit ff88cd59
-
由 Jiri Denemark 提交于
Because qemuDomainDefCopy needs a string representation of a domain definition, there's no reason for calling the lower level qemuDomainDefFormatBuf API. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
virDomainDefFormatInternal (called by qemuDomainDefFormatXMLInternal) already checks for buffer errors and properly resets the buffer on failure. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Michal Privoznik 提交于
In my previous commit of b1d87f9a I've made a typo breaking the FreeBSD build. s/ipAaddr/ipAddr/ Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Guido Günther 提交于
instead of only unloading it. This makes sure old profiles don't pile up in /etc/apparmor.d/libvirt and we get updates to modified templates on VM restart. Reviewed-by: NJim Fehlig <jfehlig@suse.com>
-
由 Laine Stump 提交于
After commit 8708ca01 libvirtd consistently aborts with "stack smashing detected" when nodedev driver is initialized. This is caused by nlmsg_parse() being told that its array of nlattr* has CTRL_CMD_MAX (10) entries, when in fact it is declared to have CTRL_ATTR_MAX (8) entries. Since all the entries are initialized to NULL, the result is that nlmsg_parse is overwriting 2*(sizof(nlattr*)) bytes outside the array. Signed-off-by: NLaine Stump <laine@laine.org> Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Michal Privoznik 提交于
In aiforaf() (which exists only when building for BSD) the @ipAddr may be leaked. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 John Ferlan 提交于
Commit id '5604c056' used the wrong API to generate the <secret type='%s'..." field. The previous code used the correct API as was done in commit id '6887af39'. The data is actually a usage type not an auth type even though the result is the same.
-
由 John Ferlan 提交于
Move the virSecretUsageType into the util.
-
由 Ashish Mittal 提交于
Passing a NULL value for the argument secAlias to the function qemuDomainGetTLSObjects would cause a segmentation fault in libvirtd. Changed code to check before dereferencing a NULL secAlias. Signed-off-by: NAshish Mittal <ashmit602@gmail.com>
-
由 Boris Fiuczynski 提交于
Adding s390x qemu caps test for qemu version 2.10.0. Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
-
- 21 9月, 2017 4 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1448268 When migrating to a file (e.g. when doing 'virsh save file'), couple of things are happening in the thread that is executing the API: 1) the domain obj is locked 2) iohelper is spawned as a separate process to handle all I/O 3) the thread waits for iohelper to finish 4) the domain obj is unlocked Now, the problem is that while the thread waits in step 3 for iohelper to finish this may take ages because iohelper calls fdatasync(). And unfortunately, we are waiting the whole time with the domain locked. So if another thread wants to jump in and say copy the domain name ('virsh list' for instance), they are stuck. The solution is to unlock the domain whenever waiting for I/O and lock it back again when it finished. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1471225 Commit id '99a2d6af' was a bit too aggressive with determining whether the provided path was a "physical" cd-rom in order to generate a taint message due to the possibility of some guest and host trying to control the tray. For cd-rom guest devices backed to some VIR_STORAGE_TYPE_FILE storage, this wouldn't be a problem and as such it shouldn't be a problem for guest devices using some sort of block device on the host such as iSCSI, LVM, or a Disk pool would present. So before issuing a taint message, let's check if the provided path of the VIR_STORAGE_TYPE_BLOCK backed device is a "known" physical cdrom name by comparing the beginning of the path w/ "/dev/cdrom" and "/dev/sr". Also since it's possible the provided path could resolve to some /dev/srN device, let's get that path as well and perform the same check. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
The virSocketAddrFormat() allocates the string and it's caller responsibility to free it afterwards. ==28857== 11 bytes in 1 blocks are definitely lost in loss record 37 of 168 ==28857== at 0x4C2BEDF: malloc (vg_replace_malloc.c:299) ==28857== by 0x9A81D79: strdup (in /lib64/libc-2.23.so) ==28857== by 0x5DA3BF0: virStrdup (virstring.c:902) ==28857== by 0x5D96182: virSocketAddrFormatFull (virsocketaddr.c:427) ==28857== by 0x5D95E13: virSocketAddrFormat (virsocketaddr.c:352) ==28857== by 0x5706890: qemuBuildHostNetStr (qemu_command.c:3891) ==28857== by 0x57138D3: qemuBuildInterfaceCommandLine (qemu_command.c:8597) ==28857== by 0x5713D6A: qemuBuildNetCommandLine (qemu_command.c:8699) ==28857== by 0x57176F6: qemuBuildCommandLine (qemu_command.c:10027) ==28857== by 0x5769D61: qemuProcessCreatePretendCmd (qemu_process.c:6004) ==28857== by 0x4056EC: testCompareXMLToArgv (qemuxml2argvtest.c:502) ==28857== by 0x41DF40: virTestRun (testutils.c:180) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jiri Denemark 提交于
Since commit v2.2.0-199-g7ce711a3 libvirt stores an updated guest CPU in domain's live definition and there's no need to update it every time we want to format the definition. The commit itself tried to address this in qemuDomainFormatXML, but forgot to fix qemuDomainDefFormatLive. Not to mention that masking a previously set flag is only acceptable if the flag was set by a public API user. Internally, libvirt should have never set the flag in the first place. https://bugzilla.redhat.com/show_bug.cgi?id=1485022Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-