- 25 7月, 2018 13 次提交
-
-
由 Daniel P. Berrangé 提交于
Consider creating a listener socket from a hostname that resolves to multiple addresses. It might be the case that the hostname resolves to both an IPv4 and IPv6 address because it is reachable over both protocols, but the IPv6 connectivity is provided off-host. In such a case no local NIC will have IPv6 and so bind() would fail with the EADDRNOTAVAIL errno. Thus it should be treated as non-fatal as long as at least one socket was succesfully bound. Reviewed-by: NJiri Denemark <jdenemar@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
When reporting socket/bind failures we want to ensure any fatal error reported is as accurate as possible. We'll prefer reporting a bind() errno over a socket() errno, because if socket() works but bind() fails that is a more significant event. Reviewed-by: NJiri Denemark <jdenemar@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1559867 When attaching a device to the domain we need to be sure to use the correct domain definition (vm->def or vm->newDef) when calling virDomainDeviceDefParse because the post parse processing algorithms that may assign an address for the device will use whatever domain definition was passed in. Additionally, some devices (SCSI hostdev and SCSI disk) use algorithms that rely on knowing what already exists of the other type when generating the new device's address. Using the wrong VM definition could result in duplicated addresses. In the case of the bz, two hostdev's with no domain address provided were added to the running domain's config only. However, the parsing algorithm used the live domain in order to figure out the host device address resulting in the same address being used and a subsequent start failing due to duplicate address. Fix this by separating the checks/code into CONFIG and LIVE processing using the correct definition for each block and performing cleanup for both options as necessary. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> ACKed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Shi Lei 提交于
With 'switch' we can utilize the compile time enum checks which we can't rely on with plain 'if' conditions. Signed-off-by: NShi Lei <shilei.massclouds@gmx.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Marcos Paulo de Souza 提交于
Commit 77298458 changed the esx storage adapter from busLogic to lsilogic, introducing a typo. Changing it back to lsiLogic (with capital L) solves the issue. With this change, libvirt can now create volumes in ESX again. Thanks to Jaroslav Suchanek who figured out what was the issue in the first place. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1571759Signed-off-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>
-
由 Andrea Bolognani 提交于
Despite being standardized in POSIX.1-2008, the 'm' sscanf() modifier is currently not available on FreeBSD. Reimplement parsing without sscanf() to work around the issue. Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1589115 When doing a memory snapshot qemuOpenFile() is used. This means that the file where memory is saved is firstly attempted to be created under root:root (because that's what libvirtd is running under) and if this fails the second attempt is done under domain's uid:gid. This does not make much sense - qemu is given opened FD so it does not need to access the file. Moreover, if dynamicOwnership is set in qemu.conf and the file lives on a squashed NFS this is deadly combination and very likely to fail. The fix consists of using: qemuOpenFileAs(fallback_uid = cfg->user, fallback_gid = cfg->group, dynamicOwnership = false) In other words, dynamicOwnership is turned off for memory snapshot (chown() will still be attempted if the file does not live on NFS) and instead of using domain DAC label, configured user:group is set as fallback. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
The documentation to virCommandWait() function states that if @exitstatus is NULL and command finished with error -1 is returned. In other words, if @dryRunCallback is set and returns an error (by setting its @status argument to a nonzero value) we must propagate this error properly honouring the documentation (and also regular run). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
After a new iSCSI interface is successfully set up, we issue a sendtargets command. However, after 56057900 we don't update the host config which in turn makes login fail because iscsiadm is unable to find any matching record for the interface. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
When scanning for targets, iSCSI might give different results depending on the interface used. This is basically just name of config file under /etc/iscsi/ifaces to use. The file contains initiator IQN thus different results claim. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
Firstly, we can utilize virCommandSetOutputBuffer() API which will collect the command output for us. Secondly, sscanf()-ing through each line is easier to understand (and more robust) than jumping over a string with strchr(). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
This is in fact 'cleanup' label and it should be named as such. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
Perform some method clean-up to follow more accepted coding standards: * Initialize @ret to error value and prove otherwise. * Initialize *ifacename to NULL Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 24 7月, 2018 4 次提交
-
-
由 Michal Privoznik 提交于
After my change to the original patch that resulted in commit 8ed874b3 it was brought to my attention that all three defines are the same: FICLONE = BTRFS_IOC_CLONE = XFS_IOC_CLONE (as documented in ioctl_ficlone(2)). Therefore we should prefer generic FICLONE over 'specific' defines for btrfs/xfs. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Peter Krempa 提交于
If we'd fail to enter or exit the monitor the saved error would be leaked. Introduced in 8498a1e2 . Pointed out by coverity. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Marc Hartmayer 提交于
Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Marc Hartmayer 提交于
Update the length @remote_params_len only if the related @remote_params_val has also been set. Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 23 7月, 2018 8 次提交
-
-
由 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>
-
- 21 7月, 2018 5 次提交
-
-
由 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 提交于
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 10 次提交
-
-
由 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>
-