- 18 2月, 2014 1 次提交
-
-
由 Michal Privoznik 提交于
There might be some use cases, where user wants to prepare the host or its environment prior to starting a network and do some cleanup after the network has been shut down. Consider all the functionality that libvirt doesn't currently have as an example what a hook script can possibly do. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 10 2月, 2014 1 次提交
-
-
由 Peter Krempa 提交于
The code took into account only the global permissions. The domains now support per-vm DAC labels and per-image DAC labels. Use the most specific label available.
-
- 04 2月, 2014 1 次提交
-
-
由 Laine Stump 提交于
commit f094aaac changed qemuPrepareHostdevPCIDevices() such that it may modify the "backend" (vfio vs. legacy kvm) setting in the virHostdevDef. However, qemuDomainAttachHostPciDevice() (used by hotplug) copies the backend setting into a local *before* calling qemuPrepareHostdevPCIDevices(), and then later makes a decision based on that pre-change value. The result is that, if the backend had been set to "default" (i.e. not specified in the config) and was later updated to "VFIO" by qemuPrepareHostdevPCIDevices(), the qemu process' MacMemLock is not increased (as is required for VFIO device assignment). This patch delays making the local copy of backend until after its potential modification.
-
- 09 1月, 2014 1 次提交
-
-
由 Michal Privoznik 提交于
Yet another advice appeared on the Multiqueue wiki page: http://www.linux-kvm.org/page/Multiqueue#Enable_MQ_feature We should add vectors=N onto the qemu command line, where N = 2 * (number of queues) + 1.
-
- 23 12月, 2013 2 次提交
-
-
由 Laine Stump 提交于
This eliminates the misleading error message that was being logged when a vfio hostdev hotplug failed: error: unable to set user and group to '107:107' on '/dev/vfio/22': No such file or directory as documented in: https://bugzilla.redhat.com/show_bug.cgi?id=1035490 Commit ee414b5d (pushed as a fix for Bug 1016511 and part of Bug 1025108) replaced the single call to virSecurityManagerSetHostdevLabel() in qemuDomainAttachHostDevice() with individual calls to that same function in each device-type-specific attach function (for PCI, USB, and SCSI). It also added a corresponding call to virSecurityManagerRestoreHostdevLabel() in the error handling of the device-type-specific functions, but forgot to remove the common call to that from qemuDomainAttachHostDevice() - this resulted in a duplicate call to virSecurityManagerRestoreHostdevLabel(), with the second occurrence being after (e.g.) a PCI device has already been re-attached to the host driver, thus destroying some of the device nodes / links that we then attempted to re-label (e.f. /dev/vfio/22) and generating an error log that obscured the original error.
-
由 Laine Stump 提交于
This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1035490 virProcessSetMaxMemLock() (which is a wrapper over prlimit(3)) expects the memory size in bytes, but libvirt's domain definition (which was being used by qemuDomainAttachHostPciDevice()) stores all memory tuning parameters in KiB. This was being accounted for when setting MaxMemLock at domain startup time (so cold-plugged devices would work), but not for hotplug. This patch simplifies the few lines that call virProcessSetMemMaxLock(), and multiply the amount * 1024 so that we're locking the correct amount of memory. What remains a mystery to me is why hot-plug of a managed='no' device would succeed (at least on my system) while managed='yes' would fail. I guess in one case the memory was coincidentally already resident and in the other it wasn't.
-
- 10 12月, 2013 4 次提交
-
-
由 Cédric Bosdonnat 提交于
The virDomainEvent class is kept as it indicates what meta informations are valid for the children classes. This may be useful in the future.
-
由 Cole Robinson 提交于
We were unconditionally removing the device from the host list, when it should only be done on error. This fixes USB collision detection when hotplugging the same device to two guests.
-
由 Cole Robinson 提交于
If we hit a collision, we free the USB device while it is still part of our temporary USBDeviceList. When the list is unref'd, the device is free'd again. Make the initial device freeing dependent on whether it is present in the temporary list or not.
-
由 Cole Robinson 提交于
Similar to what Jiri did for cgroup setup/teardown in 05e149f9, push it all into the device handler functions so we can do the necessary prep work before claiming the device. This also fixes hotplugging USB devices by product/vendor (virt-manager's default behavior): https://bugzilla.redhat.com/show_bug.cgi?id=1016511
-
- 06 12月, 2013 1 次提交
-
-
由 Cole Robinson 提交于
They aren't used outside of qemu_hotplug.c
-
- 03 12月, 2013 1 次提交
-
-
由 Laine Stump 提交于
This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1029732 The BZ asked for the capability to change the number of queues used by a virtio-net device while the device is in use. Because the number of queues can only be set at the time the device is created, that isn't possible. However, libvirt also shouldn't be silently reporting success when someone tries to change the number of queues. So this patch flags that as an error (just as attempts to change any of the other virtio-specific parameters already do).
-
- 21 11月, 2013 3 次提交
-
-
由 Eric Farman 提交于
If a SCSI hostdev is included in an initial domain XML, without a corresponding controller statement, one is created silently when the guest is booted. When hotplugging a SCSI hostdev, a presumption is that the controller is already present in the domain either from the original XML, or via an earlier hotplug. [root@xxxxxxxx ~]# cat disk.xml <hostdev mode='subsystem' type='scsi'> <source> <adapter name='scsi_host0'/> <address bus='0' target='3' unit='1088438288'/> </source> </hostdev> [root@xxxxxxxx ~]# virsh attach-device guest01 disk.xml error: Failed to attach device from disk.xml error: internal error: unable to execute QEMU command 'device_add': Bus 'scsi0.0' not found Since the infrastructure is in place, we can also create a controller silently for use by the hotplugged hostdev device. Signed-off-by: NEric Farman <farman@linux.vnet.ibm.com>
-
由 Eric Farman 提交于
For systems without a PCI bus, attaching a SCSI controller fails: [root@xxxxxxxx ~]# cat controller.xml <controller type='scsi' model='virtio-scsi' index='0' /> [root@xxxxxxxx ~]# virsh attach-device guest01 controller.xml error: Failed to attach device from controller.xml error: XML error: No PCI buses available A similar problem occurs with the detach of a controller: [root@xxxxxxxx ~]# virsh detach-device guest01 controller.xml error: Failed to detach device from controller.xml error: operation failed: controller scsi:0 not found The qemuDomainXXtachPciControllerDevice routines made assumptions that any caller had a PCI bus. These routines now selectively calls PCI functions where necessary, and assigns the device information type to one appropriate for the bus in use. Signed-off-by: NEric Farman <farman@linux.vnet.ibm.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Eric Farman 提交于
For attach/detach of controller devices, we rename the functions to remove 'PCI' from their title. The actual separation of PCI-specific operations will be handled in the next patch. Signed-off-by: NEric Farman <farman@linux.vnet.ibm.com>
-
- 15 11月, 2013 1 次提交
-
-
由 Jiri Denemark 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1025108 So far qemuSetupHostdevCGroup was called very early during hotplug, even before we knew the device we were about to hotplug was actually available. By calling the function later, we make sure QEMU won't be allowed to access devices used by other domains. Another important effect of this change is that hopluging USB devices specified by vendor and product (but not by their USB address) works again. This was broken since v1.0.5-171-g7d763aca, when the call to qemuFindHostdevUSBDevice was moved after the call to qemuSetupHostdevCGroup, which then used an uninitialized USB address.
-
- 08 11月, 2013 1 次提交
-
-
由 Vitor de Lima 提交于
This patch moves some code in the qemuDomainAttachSCSIDisk function. The check for the existence of a PCI address assigned to the SCSI controller was moved in order to be executed only when needed. The PCI address of a controller is not necessary if QEMU_CAPS_DEVICE is supported. This fixes issues with the hotplug of SCSI disks on pseries guests.
-
- 21 10月, 2013 3 次提交
-
-
由 Laine Stump 提交于
This patch (and the two patches that precede it) resolve: https://bugzilla.redhat.com/show_bug.cgi?id=1005682 When libvirt was changed to delay the final cleanup of device removal until the qemu process had signaled it with a DEVICE_DELETED event for that device, the hostdev removal function (qemuDomainRemoveHostDevice()) was written to properly handle the removal of a hostdev that was actually an SRIOV virtual function (defined with <interface type='hostdev'>). However, the function used to search for a device matching the alias name provided in the DEVICE_DELETED message (virDomainDefFindDevice()) would search through the list of netdevs before hostdevs, so qemuDomainRemoveHostDevice() was never called; instead the netdev function, qemuDomainRemoveNetDevice() (which *doesn't* properly cleanup after removal of <interface type='hostdev'>), was called. (As a reminder - each <interface type='hostdev'> results in a virDomainNetDef which contains a virDomainHostdevDef having a parent type of VIR_DOMAIN_DEVICE_NET, and parent.data.net pointing back to the virDomainNetDef; both Defs point to the same device info object (and the info contains the device's "alias", which is used by qemu to identify the device). The virDomainHostdevDef is added to the domain's hostdevs list *and* the virDomainNetDef is added to the domain's nets list, so searching either list for a particular alias will yield a positive result.) This function modifies the qemuDomainRemoveNetDevice() to short circuit itself and call qemu DomainRemoveHostDevice() instead when the actual device is a VIR_DOMAIN_NET_TYPE_HOSTDEV (similar logic to what is done in the higher level qemuDomainDetachNetDevice()) Note that even if virDomainDefFindDevice() changes in the future so that it finds the hostdev entry first, the current code will continue to work properly.
-
由 Laine Stump 提交于
pure code movement to setup for next patch.
-
由 Laine Stump 提交于
This function was called in three places, and in each the call was qualified by a slightly different conditional. In reality, this function should only be called for a hostdev if all of the following are true: 1) mode='subsystem' 2) type='pci' 3) there is a parent device definition which is an <interface> (VIR_DOMAIN_DEVICE_NET) We can simplify the callers and make them more consistent by checking these conditions at the top ov qemuDomainHostdevNetConfigRestore and returning 0 if one of them isn't satisfied. The location of the call to qemuDomainHostdevNetConfigRestore() has also been changed in the hot-plug case - it is moved into the caller of its previous location (i.e. from qemuDomainRemovePCIHostDevice() to qemuDomainRemoveHostDevice()). This was done to be more consistent about which functions pay attention to whether or not this is one of the special <interface> hostdevs or just a normal hostdev - qemuDomainRemoveHostDevice() already contained a call to networkReleaseActualDevice() and virDomainNetDefFree(), so it makes sense for it to also handle the resetting of the device's MAC address and vlan tag (which is what's done by qemuDomainHostdevNetConfigRestore()).
-
- 10 10月, 2013 1 次提交
-
-
由 Peter Krempa 提交于
Prefer using VFIO (if available) to the legacy KVM device passthrough. With this patch a PCI passthrough device without the driver configured will be started with VFIO if it's available on the host. If not legacy KVM passthrough is checked and error is reported if it's not available.
-
- 08 10月, 2013 1 次提交
-
-
由 Peter Krempa 提交于
To simplify future patches dealing with this code, simplify and refactor some conditions to switch statements.
-
- 02 10月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
The qemuDomainChangeNet() is called when 'virsh update-device' is invoked on a NIC. Currently, we fail to update the QoS even though we have routines for that. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 26 9月, 2013 1 次提交
-
-
由 Chen Hanxiao 提交于
The return value of virDomainControllerFind >=0 means that the specific controller was found. But some functions invoke it and treat 0 as not found. This patch fix these incorrect invocation. Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>
-
- 02 9月, 2013 1 次提交
-
-
由 John Ferlan 提交于
Remove unused 'cgroup' variable in qemuDomainAttachDeviceDiskLive() to resolve coverity DEADCODE complaint
-
- 29 8月, 2013 2 次提交
-
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
When using a <interface type="network"> that points to a network with hostdev forwarding mode a hostdev alias is created for the network. This allias is inserted into the hostdev list, but is backed with a part of the network object that it is connected to. When a VM is being stopped qemuProcessStop() calls networkReleaseActualDevice() which eventually frees the memory for the hostdev object. Afterwards when the domain definition is being freed by virDomainDefFree() an invalid pointer is accessed by virDomainHostdevDefFree() and may cause a crash of the daemon. This patch removes the entry in the hostdev list before freeing the depending memory to avoid this issue. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1000973
-
- 26 8月, 2013 4 次提交
-
-
由 Michal Privoznik 提交于
If there's no hard_limit set and domain uses VFIO we still must lock the guest memory (prerequisite from qemu). Hence, we should compute the amount to be locked from max_balloon.
-
由 Jiri Denemark 提交于
We don't want tests to wait 5 seconds for an event which we know will never come.
-
由 Jiri Denemark 提交于
-
由 Jiri Denemark 提交于
-
- 22 8月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
If user requested multiqueue networking, beside multiple /dev/tap and /dev/vhost-net openings, we forgot to pass mq=on onto the -device virtio-net-pci command line. This is advised at: http://www.linux-kvm.org/page/Multiqueue#Enable_MQ_feature
-
- 19 8月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
This function is to guess the correct limit for maximal memory usage by qemu for given domain. This can never be guessed correctly, not to mention all the pains and sleepless nights this code has caused. Once somebody discovers algorithm to solve the Halting Problem, we can compute the limit algorithmically. But till then, this code should never see the light of the release again.
-
- 13 8月, 2013 1 次提交
-
-
由 Guido Günther 提交于
qemuDomainAttachVirtioDiskDevice passes NULL as domainDef which is later referenced in qemuDomainAttachVirtioDiskDevice: Program terminated with signal 11, Segmentation fault. #0 qemuBuildDeviceAddressStr (buf=buf@entry=0xb646de78, info=info@entry=0xb0a02360, qemuCaps=qemuCaps@entry=0xb8fdfdc8, domainDef=<error reading variable: Unhandled dwarf expression opcode 0xfa>, domainDef=<error reading variable: Unhandled dwarf expression opcode 0xfa>) at qemu/qemu_command.c:2869 2869 for (i = 0; i < domainDef->ncontrollers; i++) { (gdb) bt #0 qemuBuildDeviceAddressStr (buf=buf@entry=0xb646de78, info=info@entry=0xb0a02360, qemuCaps=qemuCaps@entry=0xb8fdfdc8, domainDef=<error reading variable: Unhandled dwarf expression opcode 0xfa>, domainDef=<error reading variable: Unhandled dwarf expression opcode 0xfa>) at qemu/qemu_command.c:2869 #1 0xb18ad6f8 in qemuBuildDriveDevStr (def=def@entry=0x0, disk=disk@entry=0xb0a02288, bootindex=bootindex@entry=0, qemuCaps=0xb8fdfdc8) at qemu/qemu_command.c:4316 #2 0xb18d097f in qemuDomainAttachVirtioDiskDevice (conn=conn@entry=0xb90129a8, driver=driver@entry=0xb8fe29b8, vm=vm@entry=0xb8fe0c40, disk=disk@entry=0xb0a02288) at qemu/qemu_hotplug.c:278 #3 0xb193f7ba in qemuDomainAttachDeviceDiskLive (dev=0xb0a35308, vm=0xb8fe0c40, driver=0xb8fe29b8, conn=0xb90129a8) at qemu/qemu_driver.c:6356 #4 qemuDomainAttachDeviceLive (dev=0xb0a35308, vm=0xb8fe0c40, dom=<optimized out>) at qemu/qemu_driver.c:6418 #5 qemuDomainAttachDeviceFlags (dom=dom@entry=0xb0a020b8, xml=xml@entry=0xb90953f0 "<disk type='file' device='disk'>\n <source file='/var/lib/jenkins/jobs/libvirt-tck-build/workspace/scratchdir/200-disk-hotplug/extra.img'/>\n <target dev='vdb' bus='virtio'/>\n</disk>\n", flags=3103664568, flags@entry=1) at qemu/qemu_driver.c:7079 #6 0xb193f9cb in qemuDomainAttachDevice (dom=0xb0a020b8, xml=0xb90953f0 "<disk type='file' device='disk'>\n <source file='/var/lib/jenkins/jobs/libvirt-tck-build/workspace/scratchdir/200-disk-hotplug/extra.img'/>\n <target dev='vdb' bus='virtio'/>\n</disk>\n") at qemu/qemu_driver.c:7120 #7 0xb7244827 in virDomainAttachDevice (domain=domain@entry=0xb0a020b8, xml=0xb90953f0 "<disk type='file' device='disk'>\n <source file='/var/lib/jenkins/jobs/libvirt-tck-build/workspace/scratchdir/200-disk-hotplug/extra.img'/>\n <target dev='vdb' bus='virtio'/>\n</disk>\n") at libvirt.c:10912 #8 0xb7765ddb in remoteDispatchDomainAttachDevice (args=0xb9094ef0, rerr=0xb646e1f0, client=<optimized out>, server=<optimized out>, msg=<optimized out>) at remote_dispatch.h:2296 #9 remoteDispatchDomainAttachDeviceHelper (server=0xb8fba0e8, client=0xb0a00730, msg=0xb0a350b8, rerr=0xb646e1f0, args=0xb9094ef0, ret=0xb9094dc8) at remote_dispatch.h:2274 #10 0xb72b1013 in virNetServerProgramDispatchCall (msg=0xb0a350b8, client=0xb0a00730, server=0xb8fba0e8, prog=0xb8fc21c8) at rpc/virnetserverprogram.c:435 #11 virNetServerProgramDispatch (prog=0xb8fc21c8, server=server@entry=0xb8fba0e8, client=0xb0a00730, msg=0xb0a350b8) at rpc/virnetserverprogram.c:305 #12 0xb72aa167 in virNetServerProcessMsg (msg=<optimized out>, prog=<optimized out>, client=<optimized out>, srv=0xb8fba0e8) at rpc/virnetserver.c:165 #13 virNetServerHandleJob (jobOpaque=0xb0a0a850, opaque=0xb8fba0e8) at rpc/virnetserver.c:186 #14 0xb7189108 in virThreadPoolWorker (opaque=opaque@entry=0xb8fa3250) at util/virthreadpool.c:144 #15 0xb71885e5 in virThreadHelper (data=0xb8fa32a8) at util/virthreadpthread.c:161 #16 0xb70d6954 in start_thread (arg=0xb646eb70) at pthread_create.c:304 #17 0xb704e95e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 This was found by libvirtt-tck: http://honk.sigxcpu.org:8001/job/libvirt-tck-debian-wheezy-qemu-session/1311/console
-
- 08 8月, 2013 1 次提交
-
-
由 Eric Farman 提交于
Hotplugging a single SCSI device works, but adding additional ones result in an error from QEMU: [root@gpok197 ~]# virsh attach-device guest01 blah.xml Device attached successfully [root@gpok197 ~]# virsh attach-device guest01 blah2.xml error: Failed to attach device from blah2.xml error: internal error unable to execute QEMU command 'device_add': Duplicate ID 'hostdev0' for device The hostdev ID that is created is always set to zero, regardless of the contents of the XML. Changing the index in the hotplug case to a negative one so the next available index is used. Signed-off-by: NEric Farman <farman@linux.vnet.ibm.com> Reviewed-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
-
- 06 8月, 2013 1 次提交
-
-
由 Laine Stump 提交于
We had been setting the device alias in the devinceinfo for pci controllers to "pci%u", but then hardcoding "pci.%u" when creating the device address for other devices using that pci bus. This all worked just fine until we encountered the built-in "pcie.0" bus (the PCIe root complex) in Q35 machines. In order to create the correct commandline for this one case, this patch: 1) sets the alias for PCI controllers correctly, to "pci.%u" (or "pcie.%u" for the pcie-root controller) 2) eliminates the hardcoded "pci.%u" for pci controllers when generatuing device address strings, and instead uses the controller's alias. 3) plumbs a pointer to the virDomainDef all the way down to qemuBuildDeviceAddressStr. This was necessary in order to make the aliase of the controller *used by a device* available (previously qemuBuildDeviceAddressStr only had the deviceinfo of the device itself, *not* of the controller it was connecting to). This made for a larger than desired diff, but at least in the future we won't have to do it again, since all the information we could possibly ever need for future enhancements is in the virDomainDef. (right?) This should be done for *all* controllers, but for now we just do it in the case of PCI controllers, to reduce the likelyhood of regression.
-
- 18 7月, 2013 4 次提交
-
-
由 Jiri Denemark 提交于
-
由 Jiri Denemark 提交于
-
由 Jiri Denemark 提交于
-
由 Michal Privoznik 提交于
Moreover, since virAsprintf now does report OOM error, there's no need to call virReportOOMError in error path.
-