- 20 1月, 2017 3 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Michal Privoznik 提交于
Based on work of Mehdi Abaakouk <sileht@sileht.net>. When parsing vhost-user interface XML and no ifname is found we can try to fill it in in post parse callback. The way this works is we try to make up interface name from given socket path and then ask openvswitch whether it knows the interface. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
The event needs to be emitted after the last monitor call, so that it's not possible to find the device in the XML accidentally while the vm object is unlocked. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1414393
-
- 19 1月, 2017 1 次提交
-
-
由 Daniel P. Berrange 提交于
Previously when QEMU failed "drive_add" due to an error opening a file it would report "could not open disk image" These days though, QEMU reports "Could not open '/tmp/virtd-test_e3hnhh5/disk1.qcow2': Permission denied" which we were not detecting as an error condition. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 18 1月, 2017 3 次提交
-
-
由 Peter Krempa 提交于
Move all the worker code into the appropriate file. This will also allow testing of cpu hotplug.
-
由 Peter Krempa 提交于
Extract the call to qemuDomainSelectHotplugVcpuEntities outside of qemuDomainSetVcpusLive and decide whether to hotplug or unplug the entities specified by the cpumap using a boolean flag. This will allow to use qemuDomainSetVcpusLive in cases where we prepare the list of vcpus to enable or disable by other means.
-
由 Peter Krempa 提交于
In cases where CPU hotplug is supported by qemu force the monitor to reject invalid or broken responses to 'query-cpus'. It's expected that the command returns usable data in such case.
-
- 17 1月, 2017 3 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1413922 While all the code that deals with qemu namespaces correctly detects whether we are running as root (and turn into NO-OP for qemu:///session) the actual unshare() call is not guarded with such check. Therefore any attempt to start a domain under qemu:///session shall fail as unshare() is reserved for root. The fix consists of moving unshare() call (for which we have a wrapper called virProcessSetupPrivateMountNS) into qemuDomainBuildNamespace() where the proper check is performed. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Tested-by: NRichard W.M. Jones <rjones@redhat.com>
-
由 Daniel P. Berrange 提交于
This reverts commit ae16c95f.
-
- 13 1月, 2017 2 次提交
-
-
由 Collin L. Walling 提交于
When running on s390 with a kernel that does not support cpu model checking and with a Qemu new enough to support query-cpu-model-expansion, the gathering of qemu capabilities will fail. Qemu responds to the query-cpu-model-expansion qmp command with an error because the needed kernel ioct does not exist. When this happens a guest cannot even be defined due to missing qemu capabilities data. This patch fixes the problem by silently ignoring generic errors stemming from calls to query-cpu-model-expansion. Reported-by: NFarhan Ali <alifm@linux.vnet.ibm.com> Signed-off-by: NCollin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: NJason J. Herne <jjherne@linux.vnet.ibm.com>
-
由 Michal Privoznik 提交于
When creating new /dev/* for qemu, we do chown() and copy ACLs to create the exact copy from the original /dev. I though that copying SELinux labels is not necessary as SELinux will chose the sane defaults. Surprisingly, it does not leaving namespace with the following labels: crw-rw-rw-. root root system_u:object_r:tmpfs_t:s0 random crw-------. root root system_u:object_r:tmpfs_t:s0 rtc0 drwxrwxrwt. root root system_u:object_r:tmpfs_t:s0 shm crw-rw-rw-. root root system_u:object_r:tmpfs_t:s0 urandom As a result, domain is unable to start: error: internal error: process exited while connecting to monitor: Error in GnuTLS initialization: Failed to acquire random data. qemu-kvm: cannot initialize crypto: Unable to initialize GNUTLS library: Failed to acquire random data. The solution is to copy the SELinux labels as well. Reported-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 12 1月, 2017 6 次提交
-
-
由 Jiri Denemark 提交于
The query-cpu-model-expansion is currently implemented for s390(x) only and all CPU properties it returns are booleans. However, x86 implementation will report more types of properties. Without making the code more tolerant older libvirt would fail to probe newer QEMU versions. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The qemuMonitorJSONParseCPUModelProperty function is a callback for virJSONValueObjectForeachKeyValue and is called for each key/value pair, thus it doesn't really make sense to check whether key is NULL. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Michal Privoznik 提交于
So far the decision whether /dev/* entry is created in the qemu namespace is really simple: does the path starts with "/dev/"? This can be easily fooled by providing path like the following (for any considered device like disk, rng, chardev, ..): /dev/../var/lib/libvirt/images/disk.qcow2 Therefore, before making the decision the path should be canonicalized. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
So far the namespaces were turned on by default unconditionally. For all non-Linux platforms we provided stub functions that just ignored whatever namespaces setting there was in qemu.conf and returned 0 to indicate success. Moreover, we didn't really check if namespaces are available on the host kernel. This is suboptimal as we might have ignored user setting. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
This is a simple wrapper over mount(). However, not every system out there is capable of moving a mount point. Therefore, instead of having to deal with this fact in all the places of our code we can have a simple wrapper and deal with this fact at just one place. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Due to a copy-paste error, the debug message reads: Setting up disks It should have been: Setting up inputs. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 11 1月, 2017 16 次提交
-
-
由 Laine Stump 提交于
Surprisingly there was a virDomainPCIAddressReleaseAddr() function already, but it was completely unused. Since we don't reserve entire slots at once any more, there is no need to release entire slots either, so we just replace the single call to virDomainPCIAddressReleaseSlot() with a call to virDomainPCIAddressReleaseAddr() and remove the now unused function. The keen observer may be concerned that ...Addr() doesn't call virDomainPCIAddressValidate(), as ...Slot() did. But really the validation was pointless anyway - if the device hadn't been suitable to be connected at that address, it would have failed validation before every being reserved in the first place, so by definition it will pass validation when it is being unplugged. (And anyway, even if something "bad" happened and we managed to have a device incorrectly at the given address, we would still want to be able to free it up for use by a device that *did* validate properly).
-
由 Laine Stump 提交于
This function doesn't actually reserve an entire slot any more, it reserves a single PCI address, so this name is more appropriate.
-
由 Laine Stump 提交于
This function is only called in two places, and the function itself is just adding a single argument and calling virDomainPCIAddressReserveNextAddr(), so we can remove it and instead call virDomainPCIAddressReserveNextAddr() directly. (The main motivation for doing this is to free up the name so that qemuDomainPCIAddressReserveNextSlot() can be renamed in the next patch, as its current name is now inaccurate and misleading).
-
由 Laine Stump 提交于
This function doesn't actually reserve an entire slot any more, it reserves a single PCI address, so this name is more appropriate.
-
由 Laine Stump 提交于
All occurences of the former use fromConfig=true, and that's exactly how virDomainPCIAddressReserveSlot() calls virDomainPCIaddressReserveAddr(), so just use *Slot() so that *Addr() can be made static to conf/domain_addr.c (both functions will be renamed in upcoming patches).
-
由 Laine Stump 提交于
fromConfig should be true if the caller wants virDomainPCIAddressValidate() to loosen restrictions on its interpretation of the pciConnectFlags. In particular, either PCI_DEVICE or PCIE_DEVICE will be counted as equivalent to both, and HOTPLUG will be ignored. In a few cases where libvirt was manually overriding automatic address assignment, it was setting fromConfig to false when validating the hardcoded manual override. This patch changes those to fromConfig=true as a preemptive strike against any future bugs that might otherwise surface.
-
由 Laine Stump 提交于
Although setting virDomainPCIAddressReserveAddr()'s fromConfig=true is correct when a PCI addres is coming from a domain's config, the *true* purpose of the fromConfig argument is to lower restrictions on what kind of device can plug into what kind of controller - if fromConfig is true, then a PCIE_DEVICE can plug into a slot that is marked as only compatible with PCI_DEVICE (and vice versa), and the HOTPLUG flag is ignored. For a long time there have been several calls to virDomainPCIAddressReserveAddr() that have fromConfig incorrectly set to false - it's correct that the addresses aren't coming from user config, but they are coming from hardcoded exceptions in libvirt that should, if anything, pay *even less* attention to following the pciConnectFlags (under the assumption that the libvirt programmer knew what they were doing). See commit b87703cf for an example of an actual bug caused by the incorrect setting of the "fromConfig" argument to virDomainPCIAddressReserveAddr(). Although they haven't resulted in any reported bugs, this patch corrects all the other incorrect settings of fromConfig in calls to virDomainPCIAddressReserveAddr().
-
由 Laine Stump 提交于
If a PCI device has VIR_PCI_CONNECT_AGGREGATE_SLOT set in its pciConnectFlags, then during address assignment we allow multiple instances of this type of device to be auto-assigned to multiple functions on the same device. A slot is used for aggregating multiple devices only if the first device assigned to that slot had VIR_PCI_CONNECT_AGGREGATE_SLOT set. but any device types that have AGGREGATE_SLOT set might be mix/matched on the same slot. (NB: libvirt should never set the AGGREGATE_SLOT flag for a device type that might need to be hotplugged. Currently it is only planned for pcie-root-port and possibly other PCI controller types, and none of those are hotpluggable anyway) There aren't yet any devices that use this flag. That will be in a later patch.
-
由 Laine Stump 提交于
If there are multiple devices assigned to the different functions of a single PCI slot, they will not work properly if the device at function 0 doesn't have its "multi" attribute turned on, so it makes sense for libvirt to turn it on during PCI address assignment. Setting multi then assures that the new setting is stored in the config (so it will be used next time the domain is started), preventing any potential problems in the case that a future change in the configuration eliminates the devices on all non-0 functions (multi will still be set for function 0 even though it is the only function in use on the slot, which has no useful purpose, but also doesn't cause any problems). (NB: If we were to instead just decide on the setting for multifunction at runtime, a later removal of the non-0 functions of a slot would result in a silent change in the guest ABI for the remaining device on function 0 (although it may seem like an inconsequential guest ABI change, it *is* a guest ABI change to turn off the multi bit).)
-
由 Laine Stump 提交于
setting reserveEntireSlot really accomplishes nothing - instead of going to the trouble of computing the value for reserveEntireSlot and then possibly setting *all* functions of the slot as in-use, we can just set the in-use bit only for the specific function being used by a device. Later we will know from the context (the PCI connect flags, and whether we are reserving a specific address or asking for "the next available") whether or not it is okay to allocate other functions on the same slot. Although it's not used yet, we allow specifying "-1" for the function number when looking for the "next available slot" - this is going to end up meaning "return the lowest available function in the slot, but since we currently only provide a function from an otherwise unused slot, "-1" ends up meaning "0".
-
由 Laine Stump 提交于
When keeping track of which functions of which slots are allocated, we will need to have more information than just the current bitmap with a bit for each function that is currently stored for each slot in a virDomainPCIAddressBus. To prepare for adding more per-slot info, this patch changes "uint8_t slots" into "virDomainPCIAddressSlot slot", which currently has a single member named "functions" that serves the same purpose previously served directly by "slots".
-
由 Michal Privoznik 提交于
This function is used only from code compiled on Linux. Therefore on non-Linux platforms it triggers compilation error: ../../src/qemu/qemu_domain.c:209:1: error: unused function 'qemuDomainGetPreservedMounts' [-Werror,-Wunused-function] Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
For the blockjobs, where libvirt is able to track the state internally we can fix locking of images we can remove the appropriate locks. Also when doing a pivoting operation we should not acquire the lock on any of those images since both are actually locked already. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1302168
-
由 Peter Krempa 提交于
Images that became the backing chain of the current image due to the snapshot need to be unlocked in the lock manager. Also if qemu was paused during the snapshot the current top level images need to be released until qemu is resumed so that they can be acquired properly. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1191901
-
由 Peter Krempa 提交于
The code at first changed the definition and then rolled it back in case of failure. This was ridiculous. Refactor the code so that the image in the definition is changed only when the snapshot is successful. The refactor will also simplify further fix of image locking when doing snapshots.
-
由 Peter Krempa 提交于
Libvirt is able to properly model what happens to the backing chain after a snapshot so there's no real need to redetect the data. Additionally with the _REUSE_EXT flag this might end up in redetecting wrong data if the user puts wrong backing chain reference into the snapshot image.
-
- 10 1月, 2017 6 次提交
-
-
由 Michal Privoznik 提交于
After previous commits, this function is no longer needed. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Again, there is no need to create /var/lib/libvirt/$domain.* directories in CreateNamespace(). It is sufficient to create them as soon as we need them which is in BuildNamespace. This way we don't leave them around for the whole lifetime of domain. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
The c1140eb9 got me thinking. We don't want to special case /dev in qemuDomainGetPreservedMounts(), but in all other places in the code we special case it anyway. I mean, /var/run/libvirt/$domain.dev path is constructed separately just so that it is not constructed here. It makes only a little sense (if any at all). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
If something goes wrong in this function we try a rollback. That is unlink all the directories we created earlier. For some weird reason unlink() was called instead of rmdir(). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
So far if qemu is spawned under separate mount namespace in order to relabel everything it needs an access to the security driver to run in that namespace too. This has a very nasty down side - it is being run in a separate process, so any internal state transition is NOT reflected in the daemon. This can lead to many sleepless nights. Therefore, use the transaction APIs so that libvirt developers can sleep tight again. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
The code at the very bottom of the DAC secdriver that calls chown() should be fine with read-only data. If something needs to be prepared it should have been done beforehand. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-