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

[Daniel P. Berrange]

On Fri, Dec 18, 2009 at 11:17:59AM +0000, Mark McLoughlin wrote:
> On Thu, 2009-12-17 at 09:39 +0000, Daniel P. Berrange wrote:
> > On Thu, Dec 10, 2009 at 10:22:20PM +0000, Daniel P. Berrange wrote:
> > > The XML for each address type looks like
> > > 
> > >       <address type='pci' mode='static' domain='0x0000' bus='0x1e' slot='0x07' function='0x0'/>
> > >       <address type='usb' mode='dynamic' bus='007' dev='003'/>
> > >       <address type='drive' mode='dynamic' controller='1' bus='0' unit='5'/>
> > > 
> > > 
> > > The 'mode' attribute for any of them is allowed to be either
> > > 'static' or 'dynamic'. A static address is one specified by
> > > the end user when defining the XML, while a dynamic address is
> > > one automatically chosen by libvirt/QEMU every time a guest
> > > boots. The idea of static addresses is to allow management
> > > apps to guarentee that PCI device & drive numbering never
> > > changes. This series does not actually implement static
> > > addressing for PCI yet, because it requires that we change
> > > the way we generate QEMU command line arguments. It does
> > > do static addressing for disks.
> > 
> > I'm now wondering whether we actually truely need the 'dynamic'
> > option. It already doesn't really make sense for disks. For PCI
> > though I'm not sure anyone would ever want the dynamic mode, 
> > where addresses can change at every boot. I think I should just
> > remove the 'mode' attribute here, and just have libvirt detect
> > PCI addresses the first time, and keep them the same thereafter.
> 
> Just reading the proposal now and this is the bit that jumps out at me
> most. I don't think we need the dynamic/static mode split.
> 
> For PCI, we really want to just automatically remember assigned PCI
> addresses and use them forever after - I don't see any obvious use case
> where you wouldn't want this.
> 
> Also, it strikes me that we've done this before - e.g. if you define a
> guest with an interface with no explicit MAC address, we generate one
> and save it in the config. Which is pretty much the same thing from the
> users point of view.

The thing I'm trying to avoid is having libvirt update the persistent
config files outside the context of the existing virDefineXML API, and
updating the live state file only helps for the duration the that VM
is running. Hence I came up with the static vs dynamic idea, where the
app would see the dynamic address, dump the XML and re-define it with
static addresses. 

The only other option I see is to explicitly assign all PCI addresses
at time of virDefineXML, and then always pass an address on the command
line to QEMU for all devices, but this doesn't work for older QEMU where
we can't set PCI addresses. 

> > The second thought is whether we should put the <address>
> > data inside a <device> element, so it looked like
> > 
> >   <device type='pci'>
> >      <address domain='0x0000' bus='0x1e' slot='0x07' function='0x0'/>
> >   </device>
> > 
> > The reason being, that I think it might be interesting to  also add in
> > the vendor / product info at a later date 
> > 
> >   <device type='pci'>
> >      <vendor id='0x8086'/>
> >      <product id='0x1234'/>
> >      <address domain='0x0000' bus='0x1e' slot='0x07' function='0x0'/>
> >   </device>
> 
> Dunno, it seems odd to have:
> 
>   <devices>
>     <interface>
>       <device>
> 
> I read that as "<devices> is a list of device objects", "<interface> is
> a specialization of the device class" ... "wtf is <device> then?"
> 
> I guess it makes some sense as a container of device information common
> to all device types, though.

The idea is that <device> gives information about the physical hardware
being emulated, and its contents are interpreted relative to the type
attribute. If we were defining libvirt XML again from scratch, it would
have been preferrable to have the relationship inverted really. 

  <devices>
    <device>
      <interface>

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