- 04 5月, 2018 4 次提交
-
-
由 Daniel P. Berrangé 提交于
Various methods return a virNWFilterIPAddrLearnReq struct, but the callers are only interested in whether the return value is non-NULL. It is thus preferrable to just return a bool. Reviewed-by: NJiri Denemark <jdenemar@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
All the code now just uses the virHashTablePtr type directly. Reviewed-by: NJiri Denemark <jdenemar@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
This removes the virNWFilterHashTableFree, virNWFilterHashTablePut and virNWFilterHashTableRemove methods, in favour of just calling the virHash APIs directly. The virNWFilterHashTablePut method was unreasonably complex because the virHashUpdateEntry already knows how to create the entry if it does not currently exist. Reviewed-by: NJiri Denemark <jdenemar@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The virNWFilterHashTable struct only contains a single virHashTable member since commit 293d4fe2 Author: Daniel P. Berrange <berrange@redhat.com> Date: Mon Mar 24 16:35:23 2014 +0000 Remove pointless storage of var names in virNWFilterHashTable Thus, this struct wrapper adds no real value over just using the virHashTable directly, but brings the complexity of needing to derefence the hashtable to call virHash* APIs, and adds extra memory allocation step. To minimize code churn this just turns virNWFilterHashTable into a typedef aliases virHashTable. Reviewed-by: NJiri Denemark <jdenemar@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 03 5月, 2018 13 次提交
-
-
由 Stefan Berger 提交于
Alter qemuBuildTPMDevStr to format the tpm-crb on the command line and use the enum range checking for valid model. Add a test case for the formation of the tpm-crb QEMU device command line. The qemuxml2argvtest changes cannot use the newer DO_TEST_CAPS_LATEST since building of the command line involves calling qemuBuildTPMBackendStr which attempts to open the path to the device (e.g. /dev/tmp0). Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Stefan Berger 提交于
QEMU on x86_64 (since v2.12) can support tpm-crb devices. Introduce qemu capabilities for this device. Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Stefan Berger 提交于
Enable the TPM CRB to be specified in the domain XML. This now allows to describe the TPM device like this: <tpm model='tpm-crb'> <backend type='passthrough'> <device path='/dev/tpm0'/> </backend> </tpm> Extend the XML schema to also allow tpm-crb. Extend the documentation. Add a test case for testing the XML parser and formatter. Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Julio Faracco 提交于
As QEMU driver, test driver does not accept slashes inside domain names. This commit fixes this problem checking slashes inside the new name when 'domrename' is executed. Signed-off-by: NJulio Faracco <jcfaracco@gmail.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Julio Faracco 提交于
The 'domrename' command needs to check if the new domain name contains the slash character. This character is not accepted by libvirt XML definition because it is an invalid char (see Cole's commit b1fc6a7b). This commit enhace the 'domrename' command adding this check. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1333232Signed-off-by: NJulio Faracco <jcfaracco@gmail.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Daniel P. Berrangé 提交于
The virStorageFileLoadBackendModule method is only used if either fs or gluster storage is built in, which doesn't happen on mingw leading to warning of an unused static function. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The storage file drivers are currently loaded as a side effect of loading the storage driver. This is a bogus dependancy because the storage file code has no interaction with the storage drivers, and even ultimately be running in a completely separate daemon. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The virStorageFileSupportsSecurityDriver and virStorageFileSupportsAccess currently just return a boolean value. This is ok because they don't have any failure scenarios but a subsequent patch is going to introduce potential failure scenario. This changes their return type from a boolean to an int with values -1, 0, 1. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 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>
-
- 02 5月, 2018 2 次提交
-
-
由 Ján Tomko 提交于
Unused since its introduction in commit <76b644c3>. Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Ján Tomko 提交于
s/atttribute/attribute/ Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
- 30 4月, 2018 5 次提交
-
-
由 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>
-
由 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 3 次提交
-
-
由 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 2 次提交
-
-
由 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 提交于
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>
-