On Fri, Oct 22, 2010 at 01:09:30AM +0200, Matthias Bolte wrote: > 2010/10/21 Daniel Veillard <veillard@xxxxxxxxxx>: > Okay, I looked at what can be done for ESX. > > Looking at the SMBIOS data from _inside_ a ESX guest using dmidecode I > can get this > > <smbios> > <table type="0"> > <entry name="Vendor">Phoenix Technologies LTD</entry> > <entry name="Version">6.00</entry> > </table> > <table type="1"> > <entry name="Manufacturer">VMware Inc.</entry> > <entry name="Product">VMware Virtual Platform</entry> > <entry name="Version">None</entry> > <entry name="Serial">VMware-[domain/uuid]</entry> > <entry name="UUID">[domain/uuid]</entry> > </table> > </smbios> > > The UUID and Serial are basically the UUID of the guest. > > Putting smbios.reflecthost = "true" (defaults to false) in the VMX > file results in > > <smbios> > <table type="0"> > <entry name="Vendor">Phoenix Technologies LTD</entry> > <entry name="Version">6.00</entry> > </table> > <table type="1"> > <entry name="Manufacturer">LENOVO</entry> > <entry name="Product">7673J3G</entry> > <entry name="Version">None</entry> > <entry name="Serial">VMware-[domain/uuid]</entry> > <entry name="UUID">[domain/uuid]</entry> > </table> > </smbios> > > So Manufacturer and Product from the type 1 table are now inherited > from the SMBIOS of the physical host. > > But this is all from inside the guest. From _outside_ the guest over > the vSphere API I can only access "LENOVO" and "7673J3G", the data of > the physical host. > > To make it even worse, it seems that none of this can be edited in any > way (apart from the Serial/UUID because this is the domain UUID). > > Therefore, I think there is no possible useful implementation for this > in the ESX driver, besides outputting static unchangeable data. Okay, I looked up for VirtualBox, and apparently there is some support for editing some of the BIOS and system entries too based on this post http://forums.virtualbox.org/viewtopic.php?t=3224 but that looks like ad-hoc, the idea of trying to push a complete SMBios implementation probably doesn't make that much sense, and a simplified indirect version like Dan suggested might be sufficient At least we should try to expose reflecthost = "true" at the libvirt level, for ESX (and QEmu/VBox once we can parse the dmidecode output). Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list