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

[Daniel P. Berrange]

On Mon, Dec 21, 2009 at 04:53:10PM +0000, Mark McLoughlin wrote:
> 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?

Either start QEMU & query it, or manually assign the addresses. Since
we are using the -nodefaults argument, we know there are no default
devices in QEMU with the exception of a PIIX3. So we can easily just
assign addresses starting at slot 2. We don't need to know how many
addresses are possible on a bus, because if we assign a slot number
that doesn't exist, then QEMU will now print an error at startup instead
of core dumping like it did previously.

> >  - 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.

I don't think thats worth bothering about since anyone using 0.11 is
having to cope with dynamic addressing.

> > 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.

The capabilities flag is just needed so that an app can validate that 
libvirt does indeed support static addressing. It allows it to change
behaviour should it deem it neccessary. eg iif static addressing is
not supported, the mgmt app might like to avoid PCI hotplug, and only
allow plugging in SCSI disks to an existing controller. 

> 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?)

Simply because starting a VM should not modify its config, since that
violates the declared semantics of the start API.

> 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.

I don't see a) being a problem anymore, since the -nodefaults argument
allows us to turn off everything QEMU does by default, so it only creates
devices for things we explicitly ask for.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|