Hi, Just a quick question/clarification: It sounds to me that this change/fix is neither very small nor does it fix a current bug (it rather changes some internals to prevent future bugs, if I understood correctly). So I'd prefer if those changes went into master rather than in 2.10, so they can get a proper round of testing before being released. What do you think?
Cheers, Thomas On Mon, Mar 31, 2014 at 1:38 PM, Apollon Oikonomopoulos <[email protected]>wrote: > 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 > -- Thomas Thrainer | Software Engineer | [email protected] | Google Germany GmbH Dienerstr. 12 80331 München Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores
