- 02 5月, 2016 5 次提交
-
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
Commit 98c5c53d partially reverted the effort to use typecasted enums for compiler notification. Turn it back.
-
由 Peter Krempa 提交于
If qemu doesn't support DEVICE_TRAY_MOVED event the code that attempts to change media would attempt to re-eject the tray even if it wouldn't be notified when the tray opened. Add a capability bit and skip retrying for old qemus.
-
由 Peter Krempa 提交于
Empty floppy drives start with tray in "open" state and libvirt did not refresh it after startup. The code that inserts media into the tray then waited until the tray was open before inserting the media and thus floppies could not be inserted. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1326660
-
- 15 4月, 2016 1 次提交
-
-
由 Peter Krempa 提交于
Rather than trying some magic calculations on our side query the monitor for the current size of the memory balloon both on hotplug and hotunplug. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1220702
-
- 13 4月, 2016 5 次提交
-
-
由 Peter Krempa 提交于
Similarly to the DEVICE_DELETED event we will be able to tell when unplug of certain device types will be rejected by the guest OS. Wire up the device deletion signalling code to allow handling this.
-
由 Peter Krempa 提交于
No need to keep two separate conditions. A slight juggling of return values is needed to accomodate virDomainObjWaitUntil.
-
由 Peter Krempa 提交于
Neither of the callers cares whether the DEVICE_DELETED event isn't supported or the event was received. Simplify the code and callers by unifying the two values and changing the return value constants so that a temporary variable can be omitted.
-
由 Peter Krempa 提交于
Callers ignore if this function returns -1 and continue as though the DEVICE_DELETED event was not received. Since we can't be sure that the event was not received we should behave as if the event was not supported and remove the device definition right away. The error fortunately won't really happen here.
-
- 07 4月, 2016 4 次提交
-
-
由 Peter Krempa 提交于
For device hotplug, the new alias ID needs to be checked in the list rather than using the count of devices. Unplugging a device that is not last in the array will make further hotplug impossible due to alias collision. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1324551
-
由 Peter Krempa 提交于
For device hotplug, the new alias ID needs to be checked in the list rather than using the count of devices. Unplugging a device that is not last in the array will make further hotplug impossible due to alias collision. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1324551
-
由 John Ferlan 提交于
When a hostdev is attached to the guest (and removed from the host), the order of operations is call qemuHostdevPreparePCIDevices to remove the device from the host, call qemuSetupHostdevCgroup to setup the cgroups, and virSecurityManagerSetHostdevLabel to set the labels. When the device is removed from the guest, the code didn't use the reverse order leading to possible issues (especially if the path to the device no longer exists). This patch will move the call to qemuTeardownHostdevCgroup to prior to reattaching the device to the host.
-
由 John Ferlan 提交于
When a hostdev is attached to the guest (and removed from the host), the order of operations is call qemuHostdevPreparePCIDevices to remove the device from the host, call qemuSetupHostdevCgroup to setup the cgroups, and virSecurityManagerSetHostdevLabel to set the labels. When the device is removed from the guest, the code didn't use the reverse order leading to possible issues (especially if the path to the device no longer exists). This patch will move the call to virSecurityManagerRestoreHostdevLabel to prior to reattaching the device to the host.
-
- 04 4月, 2016 1 次提交
-
-
由 Laine Stump 提交于
In certain cases, we need to assign a hostdevN-style alias in a case when we don't have a virDomainHostdevDefPtr (instead we have a virDomainNetDefPtr). Since qemuAssignDeviceHostdevAlias() doesn't use anything in the virDomainHostdevDef except the alias string itself anyway, this patch just changes the arguments to pass a pointer to the alias pointer instead.
-
- 29 3月, 2016 1 次提交
-
-
由 Peter Krempa 提交于
We've started to assume support for QEMU_CAPS_DEVICE. Doing so in the SCSI disk hotplug code allows us to drop a lot of ugly legacy code.
-
- 23 3月, 2016 1 次提交
-
-
由 Vasiliy Tolstov 提交于
If a user specify network type ethernet, then create it via libvirt and run script if it provided. After this commit user does not need to run external script to create tap device or add root permissions to qemu process. Signed-off-by: NVasiliy Tolstov <v.tolstov@selfip.ru>
-
- 22 3月, 2016 1 次提交
-
-
由 Pavel Hrdina 提交于
QEMU changed the error message to: "Tray of device 'drive-sata0-0-1' is not open" and they may change the error massage in the future. This updates the code to not depend on the text from the error message but only on error itself. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 01 3月, 2016 1 次提交
-
-
由 Shanzhi Yu 提交于
in commit 81a110, multiqueue for macvtap is enabled but forget to support hotplugging enabled Signed-off-by: NShanzhi Yu <shyu@redhat.com>
-
- 25 2月, 2016 1 次提交
-
-
由 Osier Yang 提交于
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1298070 The corresponding chardev must be attached first, otherwise the the qemu command line won't be complete (missing the host part),
-
- 17 2月, 2016 5 次提交
-
-
由 John Ferlan 提交于
Create a new module qemu_alias.c to handle the qemuAssign*Alias* APIs and the qemuDomainDeviceAliasIndex
-
由 John Ferlan 提交于
Move function to qemu_interface.c and rename to qemuInterfaceOpenVhostNet Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Create new modules qemu_domain_address.c and qemu_domain_address.h to contain all the new functions and header data. Additionally move any supporting static functions. Make qemuDomainSupportsPCI non static. Also, move and rename the following: qemuSetSCSIControllerModel to qemuDomainSetSCSIControllerModel qemuCollectPCIAddress to qemuDomainCollectPCIAddress qemuValidateDevicePCISlotsPIIX3 to qemuDomainValidateDevicePCISlotsPIIX3 qemuAssignDevicePCISlots to qemuDomainAssignDevicePCISlots Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Move the misplaced function from qemu_command.c to qemu_interface.c since it's closer in functionality there and had less to do with building the command line. Rename function to qemuInterfaceBridgeConnect and modify callers. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Move the misplaced function from qemu_command.c to qemu_interface.c since it's closer in functionality there and had less to do with building the command line. Rename function to qemuInterfaceDirectConnect and modify callers. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 16 2月, 2016 1 次提交
-
-
由 Ludovic Beliveau 提交于
Currently, on hot unplug of PCI devices with VFIO driver for QEMU, libvirt is trying to restore the host devices to it's previous value (basically a chown on the previous user/group). However for devices with VFIO driver, when the device is unbinded it is removed from the /dev/vfio file system causing the restore label to fail. The fix is to not restore the label for those PCI devices since they are going to be teared down anyway. Signed-off-by: NLudovic Beliveau <ludovic.beliveau@windriver.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 08 2月, 2016 7 次提交
-
-
由 Peter Krempa 提交于
Move the logic from virDomainDiskDefDstDuplicates into virDomainDiskDefCheckDuplicateInfo so that we don't have to loop multiple times through the array of disks. Since the original function was called in qemuBuildDriveDevStr, it was actually called for every single disk which was quite wasteful. Additionally the target uniqueness check needed to be duplicated in the disk hotplug case, since the disk was inserted into the domain definition after the device string was formatted and thus virDomainDiskDefDstDuplicates didn't do anything in that case.
-
由 Peter Krempa 提交于
We do the check on VM start, but the user could still hotplug a disk with a conflicting serial or WWN. Reuse the checker function to fix the issue.
-
由 Peter Krempa 提交于
Target uniqueness check was duplicated in all of the three workers called from it. Extract it to the parent.
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
Remove the default case since all cases are covered.
-
- 17 12月, 2015 4 次提交
-
-
由 Ján Tomko 提交于
This function calls qemuDomainAttachControllerDevice for SCSI controllers and reports an error for all other controllers. Move the error inside qemuDomainAttachControllerDevice and delete this wrapper.
-
由 Andrea Bolognani 提交于
We increase the limit before plugging in a PCI hostdev or a memory module because some memory might need to be locked due to eg. VFIO. Of course we should do the opposite after unplugging a device: this was already the case for memory modules, but not for PCI hostdevs.
-
由 Andrea Bolognani 提交于
Replace all uses of the qemuDomainRequiresMlock/virProcessSetMaxMemLock combination with the equivalent qemuDomainAdjustMaxMemLock() call.
- 15 12月, 2015 1 次提交
-
-
由 Laine Stump 提交于
when appropriate, of course. If the config for a domain specifies boot order with <boot dev='blah'/> elements, e.g.: <os> ... <boot dev='hd'/> <boot dev='network'/> </os> Then the first disk device in the config will have ",bootindex=1" appended to its qemu commandline -device options, and the first (and *only* the first) network interface device will get ",bootindex=2". However, if the first network interface device is a "hostdev" device (an SRIOV Virtual Function (VF) being assigned to the domain with vfio), then the bootindex option will *not* be appended. This happens because the bootindex=n option corresponding to the order of "<boot dev='network'/>" is added to the -device for the first network device when network device commandline args are constructed, but if it's a hostdev network device, its commandline arg is instead constructed in the loop for hostdevs. This patch fixes that omission by noticing (in bootHostdevNet) if the first network device was a hostdev, and if so passing on the proper bootindex to the commandline generator for hostdev devices - the result is that ",bootindex=2" will be properly appended to the first "network" device in the config even if it is really a hostdev (including if it is assigned from a libvirt network pool). (note that this is only the case if there is no <bootmenu enabled='yes'/> element in the config ("-boot menu-on" in qemu) , since the two are mutually exclusive - when the bootmenu is enabled, the individual per-device bootindex options can't be used by qemu, and we revert to using "-boot order=xyz" instead). If a greater level of control over boot order is desired (e.g., more than one network device should be tried, or a network device other than the first one encountered in the config), then <boot dev='network'/> in the <os> element should not be used; instead, the individual device elements in the config should be given a "<boot order='n'/> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1278421
-
- 11 12月, 2015 1 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1240439 Ta-da! Now that we know how to open a macvtap device multiple times, we can finally enable the multiqueue feature. Everything else is already prepared (e.g. command line generation) from the previous iteration where the feature was implemented for TUN/TAP devices. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-