[libvirt] [PATCH 0/12] Standardized device addressing & SCSI controller/disk hotplug

[Mark McLoughlin]

On Fri, 2009-12-18 at 14:32 +0000, Daniel P. Berrange wrote:
> Actually I think I've been thinking about dynamic vs static at the wrong
> level. It isn't something that needs to be considered per device. It is
> a property of the QEMU version the guest runs, and we can figure that out
> at time of define.
> 
>  - For QEMU >= 0.12, all devices support static PCI addressing, so we
>    can easily assign all PCI addrs at time of virDefineXML and this
>    address info gets saved to disk.

How would you do the address allocation in libvirt? Would you start qemu
and query which addresses have been assigned already? Would you have
knowledge in libvirt about e.g. how many devices can be assigned to a
bus?

>  - For QEMU < 0.12, no devices support static PCI addressing, so we will
>    always query for assigned PCI addrs at time of startup and have no 
>    need to ever save this info to disk, since the QEMU doesn't support
>    static addressing

It'd be nice to remember the assigned addresses for a 0.11 guest so that
when the host is upgraded to 0.12 we can request the same addresses that
were used when running on 0.11.

> At most we need to indicate in the capabilities XML that a guest type
> supports PCI addressing, merely as a piece of useful info for PCI. They
> would never have to actually set any PCI addrs themselves. 

You've kind of lost me here. From the API user's point of view, there
are two ways you might want this handled:

  1) Don't specify a device address in the guest config, but whatever 
     address ultimately gets assigned is then stored in the guest
     config so that it never changes

     I don't see that it matters so much when the address assignment 
     happens - e.g. it could be assigned at 'define' or assigned at 
     'start' - all that matters is once the guest OS has seen the 
     device assigned at that address, then the address shouldn't change 
     thereafter

  2) Obtain information on what addresses are available for assignment 
     and assign an address to a device before attaching it to the guest 
     config

     Personally, I don't think this is terribly useful and I'm not sure 
     we're totally clear on the real details of the use case - e.g. we 
     could have a "give me an unallocated address of type 'PCI'" API, 
     but why would someone use that instead of (1). We could have a 
     "give me a list of of available slots for bus Y" API, but if we 
     were e.g. going to have a PCI specific dialog in virt-manager for 
     arranging the PCI topology, maybe it's fine for virt-manager to 
     have a load of PCI specific knowledge.

So, I think we're really just talking about (1), but it's a question of
whether libvirt should allow qemu to allocate addresses, or have libvirt
itself allocate them.

I think it's easier to just allow qemu allocate the addresses and have
libvirt query the result. But this means changing the guest config at
'start', which you're saying we should avoid. (Why?)

If libvirt does the address assignment itself at 'define', I guess we
only have two fairly minor problems - a) making sure the allocation
scheme is safe against future qemu changes and b) not being able to have
address for guests created on a host with < 0.12.

Cheers,
Mark.