mirror of https://gitee.com/openkylin/libvirt.git
2 Commits
| Author | SHA1 | Message | Date |
|---|---|---|---|
John Ferlan
|
e0e290552b |
disk: Disallow duplicated target 'dev' values
https://bugzilla.redhat.com/show_bug.cgi?id=1142631 This patch resolves a situation where the same "<target dev='$name'...>" can be used for multiple disks in the domain. While the $name is "mostly" advisory regarding the expected order that the disk is added to the domain and not guaranteed to map to the device name in the guest OS, it still should be unique enough such that other domblk* type operations can be performed. Without the patch, the domblklist will list the same Target twice: $ virsh domblklist $dom Target Source ------------------------------------------------ sda /var/lib/libvirt/images/file.qcow2 sda /var/lib/libvirt/images/file.img Additionally, getting domblkstat, domblkerror, domblkinfo, and other block* type calls will not be able to reference the second target. Fortunately, hotplug disallows adding a "third" sda value: $ qemu-img create -f raw /var/lib/libvirt/images/file2.img 10M $ virsh attach-disk $dom /var/lib/libvirt/images/file2.img sda error: Failed to attach disk error: operation failed: target sda already exists $ BUT, it since 'sdb' doesn't exist one would get the following on the same hotplug attempt, but changing to use 'sdb' instead of 'sda' $ virsh attach-disk $dom /var/lib/libvirt/images/file2.img sdb error: Failed to attach disk error: internal error: unable to execute QEMU command 'device_add': Duplicate ID 'scsi0-0-1' for device $ Since we cannot fix this issue at parsing time, the best that can be done so as to not "lose" a domain is to make the check prior to starting the guest with the results as follows: $ virsh start $dom error: Failed to start domain $dom error: XML error: target 'sda' duplicated for disk sources '/var/lib/libvirt/images/file.qcow2' and '/var/lib/libvirt/images/file.img' $ Running 'make check' found a few more instances in the tests where this duplicated target dev value was being used. These also exhibited some duplicated 'id=' values (negating the uniqueness argument of aliases) in the corresponding .args file and of course the *xmlout version of a few input XML files. |
|
|
Laine Stump
|
3ceb4c7df6 |
qemu: set/validate slot/connection type when assigning slots for PCI devices
Since PCI bridges, PCIe bridges, PCIe switches, and PCIe root ports all share the same namespace, they are all defined as controllers of type='pci' in libvirt (but with a differing model attribute). Each of these controllers has a certain connection type upstream, allows certain connection types downstream, and each can either allow a single downstream connection at slot 0, or connections from slot 1 - 31. Right now, we only support the pci-root and pci-bridge devices, both of which only allow PCI devices to connect, and both which have usable slots 1 - 31. In preparation for adding other types of controllers that have different capabilities, this patch 1) adds info to the qemuDomainPCIAddressBus object to indicate the capabilities, 2) sets those capabilities appropriately for pci-root and pci-bridge devices, and 3) validates that the controller being connected to is the proper type when allocating slots or validating that a user-selected slot is appropriate for a device.. Having this infrastructure in place will make it much easier to add support for the other PCI controller types. While it would be possible to do all the necessary checking by just storing the controller model in the qemyuDomainPCIAddressBus, it greatly simplifies all the validation code to also keep a "flags", "minSlot" and "maxSlot" for each - that way we can just check those attributes rather than requiring a nearly identical switch statement everywhere we need to validate compatibility. You may notice many places where the flags are seemingly hard-coded to QEMU_PCI_CONNECT_HOTPLUGGABLE | QEMU_PCI_CONNECT_TYPE_PCI This is currently the correct value for all PCI devices, and in the future will be the default, with small bits of code added to change to the flags for the few devices which are the exceptions to this rule. Finally, there are a few places with "FIXME" comments. Note that these aren't indicating places that are broken according to the currently supported devices, they are places that will need fixing when support for new PCI controller models is added. To assure that there was no regression in the auto-allocation of PCI addresses or auto-creation of integrated pci-root, ide, and usb controllers, a new test case (pci-bridge-many-disks) has been added to both the qemuxml2argv and qemuxml2xml tests. This new test defines a domain with several dozen virtio disks but no pci-root or pci-bridges. The .args file of the new test case was created using libvirt sources from before this patch, and the test still passes after this patch has been applied. |