On 13:37 Mon 31 Mar , Dimitris Aragiorgis wrote: > I see. The changes will be more intrusive, I guess. > > Currently, we have 'if=none,bus=0,unit=<some hex>' on the `-drive` > option and 'bus=pci.0,addr=<same hex>' on the `-device` option. > > Will this change?
No, this will not change for virtio-blk devices, but it will be different for virtio-scsi. Actually, "bus=0,unit=0" on -drive is useless with virtio-blk as well; these parameters are the "Old Way"[1] of specifying positions, meant for legacy emulated IDE and SCSI buses where you have more than one drive per controller and as far as I can tell[1], they are completely ignored when the drive is declared with "if=none". Even if they were not ignored, the virtio-blk-pci controller has exactly one disk slot, so I wouldn't expect the parameters to be used in any way. [1] see docs/qdev-device-use.txt in qemu's source. > I just saw the output of `info qtree` for an existing instance with > virtio devices. It shows that all devices are under the pci.0 bus which > makes sense. > > You mentioned the SCSI bus. `qemu-system-x86_64 -device ?` gives the > scsi-block|cd|generic|hd device types related to this bus. > > Does this bus have slots like the PCI bus? Yes, the SCSI bus has an addressing scheme of ADAPTER:BUS:TARGET:LUN. This has nothing to do with the "bus" and "unit" of "-drive", instead we can control the target and lun placement via the "scsi-id" (target) and "lun" params to "-device scsi-hd". So yes, SCSI does have slots in a sense and two levels of them are assignable (target and LUN) - just like PCI also has multi-function devices with (slot, function) tuples. The other good news is that changing from plain SCSI to virtio-SCSI is just a matter of replacing the controller, the drive and device specifications remain the same :-). > If yes are their order important? The order is important, in the same way the PCI slot order is important: the bus is scanned in target:lun order, so target 0 lun 0 will be scanned before target 0 lun 1 and that before target 1 lun 0 respectively. A big advantage here is that SCSI disks can contain their own unique IDs (derived e.g. from their UUID), that can be used by the guest OS to construct persistent names, regardless of their bus position. Under Linux this would mean /dev/disk/by-path/..., which is currently unavailable with virtio-blk-pci. > And how are we going to preserve them upon migrations? (Almost) the same way it is currently done for PCI slots, only accounting for SCSI bus positions this time. > From the qemu man page I see the following: > > You can connect a SCSI disk with unit ID 6 on the bus #0: > > qemu-system-i386 -drive file=file,if=scsi,bus=0,unit=6 This is for legacy SCSI devices only. Virtio-scsi uses -drive if=none,file=<file>,id=<drive_id> -device scsi-hd,drive=<drive_id>,scsi-id=0,lun=6. > `unit` is used currently in the PCI bus too. I guess this is similar. Well, as I explained above, it is *redundantly* used in the "-drive" option of virtio-blk devices and doesn't do much there. You can leave it out and the result will be the same. > > To hotplug a device we parse the output of `info pci` to find the > available slots. How are we going to get the corresponding info > for other buses? Currently there is no way to list the (virtio-)SCSI or IDE buses from the monitor, so we either have to account for them externally, or try hotplugging until a free slot is found and save the result. In any case, the difference here is that it's much safer to assume that we have exclusive control of the SCSI bus addressing; adding or removing a balloon device or a sound card will never mess with the devices on the SCSI bus. Note that this is actually only relevant for live migrations, where we want to reconstruct the PCI/SCSI layout across the two instances. Hotplugging per se can be performed without specifying slots/bus positions, in which case qemu will happily assign the first available position. > > I think the rationale there would be to have two distinct functions: > > PCI device hotplugging and drive hotplugging (`device_add' and > > `drive_add' in qemu terms). Virtio-blk disks currently need both, a > > disk hotplug and a PCI hotplug. NIC hotplugging needs only PCI > > hotplug and (virtio-)SCSI needs only a disk hotplug¹. Currently > > these two functions are interleaved and depend on a PCI slot being > > available to encode in the id, but it shouldn't be too difficult to > > factor that out. I'll have a look at this as well. > > > > Well the device id includes the PCI slot. This can be removed I guess since > it is not more than extra info. Exactly, I have prepared patches that use an opaque "hypervisor ID" field for all hotplug operations, instead of deriving the device ID from the PCI slot. However, in order to facilitate plain SCSI and virtio-scsi as well, "pci" will have to be converted to a generic "address" slot, which will be device-type-specific (PCI slot for virtio-blk, SCSI address for scsi disks). > > > ¹ Note that even virtio-scsi uses the -device syntax with the scsi-hd > > driver, but does not yield back a PCI device. So `-device` does not > > necessarily imply a PCI slot is available. > > > > And a small question re: PCI slot reassignment: from your tests at > > GRNET, do you happen to know what is the threshold of moving PCI devices > > around that will trigger a re-activation in Windows? > > > > On an already activated Windows 2012, after shifting the disks, the > expiration date of the Licence did not change, so I guess it did not > trigger a re-activation. > > In a Windows 2008R2 after step 4 it said that "New Hardware found" and > successfully re-installed all virtio drivers (balloon, Ethernet, SCSI). > Besides that the network adapters were renumbered (minor) and that > Windows recommended a restart (not really necessary), the VM was working > fine. Good to know, thanks! Cheers, Apollon
