- 23 7月, 2018 17 次提交
-
-
由 Peter Krempa 提交于
Few disk tests were testing support for pure -drive command line generation for disks now that we assume it for all qemu versions the cases are obsolete. Replacements: disk-readonly-no-device -> disk-readonly-disk disk-floppy-tray-no-device -> disk-floppy-tray disk-cdrom-tray-no-device -> disk-cdrom-tray Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
We also have disk-copy_on_read.xml which also tests the command line. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Andrea Bolognani 提交于
We finally get rid of the strncpy()-like semantics and implement our own, more sensible ones instead. As a bonus, this also fixes compilation on MinGW. Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Andrea Bolognani 提交于
We're going to change virStrncpy() in a way that requires the source string to be NULL-terminated, so we'll no longer be able to use in this context. Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Andrea Bolognani 提交于
Currently, the functions return a pointer to the destination buffer on success or NULL on failure. Not only does this kind of error handling look quite alien in the context of libvirt, where most functions return zero on success and a negative int on failure, but it's also somewhat pointless because unless there's been a failure the returned pointer will be the same one passed in by the user, thus offering no additional value. Change the functions so that they return an int instead. Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Andrea Bolognani 提交于
The strncpy() function has this quirk where it will copy *up* to the requested number of bytes, that is, it will stop early if it encounters a NULL byte in the source string. This makes it legal to pass the size of the destination buffer (minus one byte needed for the string terminator) as the number of bytes to copy and still get something somewhat reasonable out of the operation; unfortunately, it also makes the function difficult to reason about and way too easy to misuse. We want to move away from the way strncpy() behaves and towards better defined semantics, where virStrncpy() will always copy *exactly* the number of bytes it's been asked to copy; before we can do that, though, we have to change a few of the callers. Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Andrea Bolognani 提交于
virStrncpy() allows us to copy a substring, but if we're going to copy the entire thing it's much more convenient to use virStrcpy() instead. Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Andrea Bolognani 提交于
virStrcpy() and friends are useful when the destination buffer has already been allocated, eg. as part of a struct; if we have to allocate it on the spot, VIR_STRDUP() is a better choice. Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Andrea Bolognani 提交于
This convenience macro was created for the simple cases where the length of the source string and the size of the destination buffer can be figued out with strlen() and sizeof() respectively, so we should use it wherever possible instead of open-coding parts of it. Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Andrea Bolognani 提交于
The way virStrncpy() is called here will never result in buffer overflow, but it won't prevent or detect truncation either, despite what the error message might suggest. Use virStrcpyStatic(), which does all of the above, instead. Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Daniel P. Berrangé 提交于
All our supported RHEL and Fedora versions include systemd, so we can assume it is always present in the spec. Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
We no longer build on RHEL-6, so can bump min required RHEL to 7 removing many conditions. Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
When gnutls negotiates TLS 1.3 instead of 1.2, the order of messages sent by the handshake changes. This exposed a logic bug in the test suite which caused us to wait for the server to see handshake completion, but not wait for the client to see completion. The result was the client didn't receive the certificate for verification and the test failed. This is exposed in Fedora 29 rawhide which has just enabled TLS 1.3 in its GNUTLS builds. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Han Han 提交于
Add --alias to support custom alias in virsh attach-interface. Signed-off-by: NHan Han <hhan@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Han Han 提交于
Add --alias to support custom disk alias in virsh attach-disk. Signed-off-by: NHan Han <hhan@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 21 7月, 2018 6 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1603025 Commit b57a9aec neglected to VIR_FREE(binding->filtername) as seen in the following valgrind report ==6423== 17,328 bytes in 1,083 blocks are definitely lost in loss record 2,275 of 2,297 ==6423== at 0x4C29BC3: malloc (vg_replace_malloc.c:299) ==6423== by 0x83B20C9: strdup (in /usr/lib64/libc-2.17.so) ==6423== by 0x533C144: virStrdup (virstring.c:977) ==6423== by 0x54BDD53: virGetNWFilterBinding (datatypes.c:865) ==6423== by 0x318D633C: nwfilterBindingCreateXML (nwfilter_driver.c:767) ==6423== by 0x54F3FC5: virNWFilterBindingCreateXML (libvirt-nwfilter.c:701) ==6423== by 0x539CE29: virDomainConfNWFilterInstantiate (domain_nwfilter.c:116) ==6423== by 0x31E516C2: qemuInterfaceBridgeConnect (qemu_interface.c:589) ==6423== by 0x31D98B56: qemuBuildInterfaceCommandLine (qemu_command.c:8418) ==6423== by 0x31D9F783: qemuBuildNetCommandLine (qemu_command.c:8673) ==6423== by 0x31D9F783: qemuBuildCommandLine (qemu_command.c:10354) ==6423== by 0x31DE355F: qemuProcessLaunch (qemu_process.c:6292) ==6423== by 0x31DE7881: qemuProcessStart (qemu_process.c:6686) and ==6423== 17,328 bytes in 1,083 blocks are definitely lost in loss record 2,276 of 2,297 ==6423== at 0x4C29BC3: malloc (vg_replace_malloc.c:299) ==6423== by 0x83B20C9: strdup (in /usr/lib64/libc-2.17.so) ==6423== by 0x533C144: virStrdup (virstring.c:977) ==6423== by 0x54BDD53: virGetNWFilterBinding (datatypes.c:865) ==6423== by 0x318D641F: nwfilterBindingLookupByPortDev (nwfilter_driver.c:678) ==6423== by 0x54F3B63: virNWFilterBindingLookupByPortDev (libvirt-nwfilter.c:593) ==6423== by 0x539CBC5: virDomainConfNWFilterTeardownImpl.isra.0 (domain_nwfilter.c:136) ==6423== by 0x539CFA5: virDomainConfVMNWFilterTeardown (domain_nwfilter.c:170) ==6423== by 0x31DE5651: qemuProcessStop (qemu_process.c:6912) ==6423== by 0x31E37974: qemuDomainDestroyFlags (qemu_driver.c:2229) ==6423== by 0x54C24BB: virDomainDestroy (libvirt-domain.c:475) ==6423== by 0x1589A2: remoteDispatchDomainDestroy (remote_daemon_dispatch_stubs.h:4827) ==6423== by 0x1589A2: remoteDispatchDomainDestroyHelper (remote_daemon_dispatch_stubs.h:4803) Signed-off-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Marc Hartmayer 提交于
The include guard should match the file name and comment. Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Marc Hartmayer 提交于
Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Marc Hartmayer 提交于
Hypervisor drivers (e.g. QEMU) assume that they run in a separate thread from the main event loop thread otherwise deadlocks can occur. Therefore let's report an error if max_workers < 1 is set in the libvirtd configuration file. Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Marc Hartmayer 提交于
...since maxWorkers=0 is only intended for virtlockd or virlogd which must not be multithreaded. Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Marc Hartmayer 提交于
@srv must be unlocked for the call virNetServerProcessMsg otherwise a deadlock can occur. Since the pointer 'srv->workers' will never be changed after initialization and the thread pool has it's own locking we can release the lock of 'srv' earlier. This also fixes the deadlock. Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 20 7月, 2018 17 次提交
-
-
由 Peter Krempa 提交于
Now that we have a saner replacement for checking if the disk source is the same use it instead of formatting qemu command-line chunks. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
To allow checking whether a storage source points to the same location add a helper which checks the relevant fields. This will allow replacing a similar check done by formatting the command line arguments for qemu-like syntax. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Extract the code for future reuse. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
The code is useful also when gathering statistics per node name, so extract it to a separate functions. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
The 'query-blockstats' command does not return statistics for the explicitly named nodes unless the new argument is specified. Add infrastrucuture that will allow us to use the new approach if desired. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Use the proper backend for the block device both when using -drive and when -blockdev will be used for disk drives and floppy disks. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
The disk backend alias was historically the alias of the -drive backing the storage. For setups with -blockdev this will become more complex as it will depend on other configs and generally will differ. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
In some cases backing chain needs to be cleared prior to re-detection. Move this step out of qemuDomainDetermineDiskChain as only certain places need it and the function itself is able to skip to the end of the chain to perform detection. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Allow updating capacity for the block devices returned by qemuDomainBlocksStatsGather and replace the open-coded call to qemuMonitorGetAllBlockStatsInfo by the helper. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Despite the warning that virStorageSourceCopy needs to be populated on additions to the structure commit 68773054 neglected to implement the copy function. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
When changing cdrom media we did not handle the managed PR objects thus we'd either have a stale PR object left behind or the media change would fail. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Remove the issue of the monitor command to the caller so that the function can be used with the modern approach. Additionally improve the error message. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Prepare for the -blockdev implementation of ejectable media changing by splitting up the old bits. Additionally since both callers make sure that the device is a cdrom or floppy the check is no longer necessary. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Similarly to qemuDomainDiskRemoveManagedPR make it enter monitor on its own so that it can be reused. Future users will be in the snapshot code and in removable media change code. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Extract the (possible) removal of the PR backend and daemon into a separate helper which enters monitor on its own. This simplifies the code and allows reuse of this function in the future e.g. for blockjobs where removing a image with PR may result into PR not being necessary. Since the PR is not used often the overhead of entering monitor again should be negligible. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Add code which will convert a disk definition into qemuHotplugDiskSourceData and then reuse qemuHotplugDiskSourceRemove to remove all the backend related objects. This unifies the detach code as much as possible with the already existing helpers and will allow reuse this infrastructure when changing removable disk media. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
qemuDomainRemoveDiskDevice would leak the disk to be removed if the VM crashed since it was removed from the definition but not freed. Broken in commit 105bcdde which moved the removal from the definition earlier. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-