- 03 5月, 2018 9 次提交
-
-
由 Daniel P. Berrangé 提交于
The virStorageFileGetBackingStoreStr method has overloaded the NULL return value to indicate both no backing available and a fatal error dealing with it. The caller is thus not able to correctly propagate the error messages. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The storage file code needs to be run in the hypervisor drivers, while the storage backend code needs to be run in the storage driver. Split the source code as a preparatory step for creating separate loadable modules. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The storage file code needs to be run in the hypervisor drivers, while the storage backend code needs to be run in the storage driver. Split the source code as a preparatory step for creating separate loadable modules. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The driver.{c,h} files are primarily targetted at loading hypervisor drivers and some helper functions in that area. It also, however, contains a generically useful function for loading extension modules that is called by the storage driver. Split that functionality off into a new virmodule.{c,h} file to isolate it. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Ville Skyttä 提交于
Signed-off-by: NVille Skyttä <ville.skytta@iki.fi>
-
由 Daniel P. Berrangé 提交于
The wireshark plugin directory moved again in Fedora 29, and will move again every time wireshark do a new minor release. Call out to pkg-config to find the right directory to use in the RPM file list. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Snce the xen driver was deleted we need to ensure that the old libvirt-daemon-driver-xen sub-RPM gets removed on upgrade. We achieve this my making libvirt-daemon-driver-libxl obsolete it. We don't add a Provides: too, because libvirt-daemon-driver-libxl is not a functionally identical replacement, since we don't want to satisfy deps for 3rd party apps that have a Requires on the libvirt-daemon-driver-xen RPM. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Maciej Wolny 提交于
Fixes "can't find libtool" error when running valgrind checks. Signed-off-by: NMaciej Wolny <maciej.wolny@codethink.co.uk> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
- 02 5月, 2018 6 次提交
-
-
由 Ján Tomko 提交于
Unused since its introduction in commit <76b644c3>. Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Erik Skultety 提交于
Panic device has 2 optional sub-elements - <alias> and <address> the order of which should be interchangeable in the XML. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1456165Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Ján Tomko 提交于
s/atttribute/attribute/ Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Ján Tomko 提交于
Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Daniel Veillard 提交于
* docs/news.xml: updated for the release Signed-off-by: NDaniel Veillard <veillard@redhat.com>
-
由 Peter Krempa 提交于
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
- 30 4月, 2018 7 次提交
-
-
由 Peter Krempa 提交于
Use the TLS env for migration when starting the NBD server if TLS is enabled for migration. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Peter Krempa 提交于
To allow encryption of the non-shared storage migration NBD connection we will need to instantiated the NBD server with the TLS env. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Peter Krempa 提交于
The NBD server in qemu supports TLS transport. Detect this capability. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Peter Krempa 提交于
When a VM is destroyed while being migrated (waiting in qemuMigrationSrcWaitForCompletion) the private object cleanup code frees the 'current' job info. Since the migration code attempts to setup various aspects of the current job even on failure this results into a crash. Job data is cleared in qemuDomainObjPrivateDataClear since commit 888aa4b6 Fix this by skipping all of the code which requires the qemu process to be alive if the VM is not active any more. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Daniel P. Berrangé 提交于
For unknown reasons about 21 languages had the same 212 msgid entries copied into the msgstr field without having any translation applied. This bogus non-translated data has now been purged from Zanata. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Refresh transaltion po files to drop msgid/msgstr entries that are no longer required due to deletion/refactoring of source code. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Peter Krempa 提交于
Since libvirt is currently not able to setup the NBD migration stream secured by TLS we should not allow such migration since data would be transferred unencrypted. This will break compatibility of TLS migration if non-shared storage is requested but the security implications are more severe. Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
- 28 4月, 2018 1 次提交
-
-
由 Laine Stump 提交于
When an nwfilter rule sets the parameter CTRL_IP_LEARNING to "dhcp", this turns on the "dhcpsnoop" thread, which uses libpcap to monitor traffic on the domain's tap device and extract the IP address from the DHCP response. If libpcap on the host is built with HAVE_TPACKET3 defined (to enable support for TPACKET_V3), the dhcpsnoop code's initialization of the libpcap socket would fail with the following error: virNWFilterSnoopDHCPOpen:1134 : internal error: pcap_setfilter: can't remove kernel filter: Bad file descriptor It turns out that this was because TPACKET_V3 requires a larger buffer size than libvirt was setting (we were setting it to 128k). Changing the buffer size to 256k eliminates the error, and the dhcpsnoop thread once again works properly. A fuller explanation of why TPACKET_V3 requires such a large buffer, for future git spelunkers: libpcap calls setsockopt(... SOL_PACKET, PACKET_RX_RING...) to setup a ring buffer for receiving packets; two of the attributes sent to this API are called tp_frame_size, and tp_frame_nr. If libpcap was built with HAVE_TPACKET3 defined, tp_trame_size is set to MAXIMUM_SNAPLEN (defined in libpcap sources as 262144) and tp_frame_nr is set to: [the buffer size we set, i.e. PCAP_BUFFERSIZE i.e. 262144] / tp_frame_size. So if PCAP_BUFFERSIZE < MAXIMUM_SNAPLEN, then tp_frame_nr (the number of frames in the ring buffer) is 0, which is nonsensical. This same value is later used as a multiplier to determine the size for a call to malloc() (which would also fail). (NB: if HAVE_TPACKET3 is *not* defined, then tp_frame_size is set to the snaplen set by the user (in our case 576) plus a small amount to account for ethernet headers, so 256k is far more than adequate) Since the TPACKET_V3 code in libpcap actually reads multiple packets into each frame, it's not a problem to have only a single frame (especially when we are monitoring such infrequent traffic), so it's okay to set this relatively small buffer size (in comparison to the default, which is 2MB), which is important since every guest using dhcp snooping in a nwfilter rule will hold 2 of these buffers for the entire life of the guest. Thanks to Christian Ehrhardt for discovering that buffer size was the problem (this was not at all obvious from the error that was logged!) Resolves: https://bugzilla.redhat.com/1547237 Fixes: https://bugs.launchpad.net/libvirt/+bug/1758037Signed-off-by: NLaine Stump <laine@laine.org> Reviewed-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> (V1) Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Tested-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
-
- 27 4月, 2018 4 次提交
-
-
由 Daniel P. Berrangé 提交于
This reverts commit 209d4d6f. The wildcard feature has been temporarily removed pending re-impl. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
This reverts commit 8daa593b. There are two undesirable aspects to the impl - Only a bare wildcard is permitted - The wildcard match is not performed in the order listed Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Peter Krempa 提交于
The code setting TLS parameters verifies that TLS is supported by looking at the dump of parameters which will be reset after migration, but sets the parameters in the list of new parameters. As qemuMigrationParamsSetString did not set the 'set' property, the TLS parameters would not be used. This is a regression after the series refactoring migration parameters and it resulted into TLS not being used even when requested. Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Peter Krempa 提交于
The function is not used outside of the src/qemu/qemu_migration_params.c file so unexport it. Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
- 26 4月, 2018 3 次提交
-
-
由 Martin Kletzander 提交于
That is a job of libvirtd and virtlogd has a dependency on it, so that will prevent it properly. Doing it one extra time in virtlogd might also cause AVC denials because it is not allowed to call that dbus method. Caused by commit df34363d. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1547250Signed-off-by: NMartin Kletzander <mkletzan@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Ján Tomko 提交于
The script assumed to be run in the source directory. Pass top_srcdir as the argument to fix VPATH builds. My commit 81a7571 broke this. Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Ján Tomko 提交于
Introduce a perl script that is able to regroup both the QEMU_CAPS constants and the capability strings. Check correct grouping as a part of syntax check. For in-place regrouping after a rebase, just run: tests/group-qemu-caps.pl without any parameters. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 25 4月, 2018 10 次提交
-
-
由 Daniel P. Berrangé 提交于
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Roman Bogorodskiy 提交于
virNetDevTapGetRealDeviceName() is used on FreeBSD because interface names (such as one sees in output of tools like ifconfig(8)) might not match their /dev entity names, and for bhyve we need the latter. Current implementation is not very efficient because in order to find /dev name, it goes through all /dev/tap* entries and tries to issue TAPGIFNAME ioctl on it. Not only this is slow, but also there's a bug in this implementation when more than one NIC is passed to a VM: once we find the tap interface we're looking for, we set its state to UP because opening it for issuing ioctl sets it DOWN, even if it was UP before. When we have more than 1 NIC for a VM, we have only last one UP because others remain DOWN after unsuccessful attempts to match interface name. New implementation just uses sysctl(3), so it should be faster and won't make interfaces go down to get name. Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Daniel P. Berrangé 提交于
The code for building UNIX socket paths will be getting more complex to cope with accessing various different daemons. Refactor it to eliminate the code duplication and isolation the logic for constructing paths. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Currently the remote driver extracts the transport from URI scheme and plays games to temporarily hide the driver part when formatting URIs. Refactor the code to split the URI scheme upfront so the two pieces are easily available where needed. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The libvirtd daemon currently ignores the return status of virDriverLoadModule entirely. This is way too loose, resulting in many important problems going undiagnosed, resulting in a libvirtd that may never work correctly. We should only ignore a non-existant module, and pass back any fatal errors. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Currently the driver module loading code does not report an error if the driver module is physically missing on disk. This is useful for distro packaging optional pieces. When the daemons are split up into one daemon per driver, we will expect module loading to always succeed. If a driver is not desired, the entire daemon should not be installed. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The driver module loading code is one of the few places that still uses VIR_ERROR for reporting failures. Convert it to normal error reporting APIs. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Currently we do a access(R_OK) check to see whether a loadable module exists, treating failure as non-fatal. This is unreasonably loose, as a module which exists but has had incorrect permissions set will turn into a silent skip. We only want to skip loading if the module genuinely does not exist on disk, due to the optional package not being installed. Furthermore, checking the return value of virDriverLoadModuleFile() is not a suitable witness that the module does not exist. This method can return NULL if dlopen() fails, for example due to being unable to resolve symbols in the library. This is should always be reported as an error because it is a sign of the bad installation where either the module build doesn't match the libvirtd build, or where some 3rd party libraries are missing or broken. Both these problems can be fixed by using virFileExists in the caller instead. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The virFileFindResource method merely builds up the expected fully qualified path to the resource. It does not actually check if it exists on disk. The loadable module callers were mistakenly thinking a NULL indicates the file doesn't exist on disk, whereas it in fact indicates an out of memory error. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Now that we've activated two hacks to prevent unloading of modules, there is no point passing back a pointer to the loaded library handle. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-