[libvirt] [PATCH] 0/4 Add SMBIOS settings to domain definition

Daniel P. Berrange berrange at redhat.com
Tue Nov 9 10:51:50 UTC 2010


On Tue, Nov 09, 2010 at 11:29:31AM +0100, Daniel Veillard wrote:
> On Tue, Nov 09, 2010 at 04:22:56AM -0500, Jon Masters wrote:
> > On Thu, 2010-10-21 at 21:52 +0200, Daniel Veillard wrote:
> > > The SMBIOS data are a standardized set of data structures available
> > > in the BIOS area of PCs. Those blocks of data describe things like
> > > BIOS version informations, machine vendor, model and identifiers,
> > > as well as various parts of the machine capability. On a linux
> > > machine running dmidecode allows to dump those informations.
> > 
> > Daniel,
> > 
> > Can you tell me if you are (or are willing or planning to) going to
> > implement structure Type 9 of the SMBIOS specification? Specifically,
> > this provides a mapping from the "system slots" (in the chassis) to the
> > PCI devices in the system (as an example), especially where network is
> > concerned (but not limited to that). We are investigating generic
> > solutions for mapping network devices presented by Linux through to the
> > physical devices themselves. So for example, network device eth0 is
> > replaced by eth-slot0-<etc> or lom0, or whatever.
> > 
> > I know virt doesn't have a physical slot, but the ordering of devices
> > does matter very much. Let me know your plans. I am still catching up
> > from LPC last week, so I just skimmed libvirt list. I have a plan to
> > read over your patches soon.
> 
>   A priori no hypervisor expose any of the type 9 informations. So
> I don't think using the SMBIOS stucture may actually help solving
> the device ordering in the guests. My pervious version of the patch
> which was very close to SMBIOS structure would have allowed to expose
> those but that's not something we could have used for the hypervisor.
> Also contrary to the current set of sysinfo informations we won't be
> able to pick them up from the host in any meaningful way.
> 
> The device ordering is still something to be improved but for a given
> class of devices we tend to assign them PCI slots in the order found
> in the XML docmain declaration. Right now the order between different
> classes of devices is hardcoded and that is one point we should be
> able to improve,

Actually that's not quite correct. If you give a XML config to libvirt
without any PCI addresses, libvirt will auto-assign slots in an order
that matches QEMU's default auto-assignment.  If you want to explicitly
control PCI addresses yourself, you can include them in the XML given
to libvirt and that will cause libvirt's autoassignment to be skipped.
So a mgmt app can guarantee a PCI slot for a given device across all
guests if it so desires

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




More information about the libvir-list mailing list