Hi, * Apollon Oikonomopoulos <[email protected]> [2014-03-28 12:31:34 +0200]:
> Hi Dimitri,
>
> On 12:18 Fri 28 Mar , Dimitris Aragiorgis wrote:
> > So from what I understand the proposed change will:
> >
> > 1) affect only virtio devices (NICs, and Disks)
> > 2) keep the current hotplug rational (only NodeD knows about PCI info)
> > 3) will change _DEFAULT_PCI_RESERVATIONS and reserve the first 8 slots
> > 4) run `info pci` to get current PCI status and find available slots
> > and "OR" them with _DEFAULT_PCI_RESERVATIONS
> > 5) revert the commit that fixes #757 in the sense that virtio balloon
> > and spice wont get PCI info.
> >
> > If I don't miss anything here, I agree with all the above. So yes,
> > please proceed with patches.
> >
> > Just one note here:
> >
> > Currently *only* virtio devices obtain PCI info and thus are
> > hotplug-able. Primarily, Ganeti used only the `-drive` option for disks.
> > Hotplug support added the `-device` option, so that they can obtain PCI
> > info. Should we adopt the `-device` option to all devices? Would this
> > make any sense?
>
> Personally, I see no reason to bind hotplugging to PCI-only devices.
> Both, plain SCSI and Virtio SCSI support disk hotplugging for instance
> and do not need a PCI slot for each disk (they hot-plug disks onto the
> SCSI bus). I think what is actually needed to store in the runtime is
> the unique device hotplug id (which can be anything as far as I
> understand), and not a PCI slot specifically. I started implementing
> virtio SCSI yesterday and hit upon this, so this also has to be changed.
>
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?
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?
If yes are their order important?
And how are we going to preserve them upon migrations?
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
`unit` is used currently in the PCI bus too. I guess this is similar.
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?
> 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.
> ¹ 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.
Cheers,
dimara
> Regards,
> Apollon
signature.asc
Description: Digital signature
