On Thu, Dec 02, 2010 at 08:12:23PM +0000, Daniel P. Berrange wrote: > On Thu, Dec 02, 2010 at 10:04:59PM +0200, Gleb Natapov wrote: > > On Thu, Dec 02, 2010 at 07:56:03PM +0000, Daniel P. Berrange wrote: > > > On Thu, Dec 02, 2010 at 09:44:47PM +0200, Gleb Natapov wrote: > > > > On Thu, Dec 02, 2010 at 10:36:59AM -0700, Eric Blake wrote: > > > > > On 12/02/2010 05:47 AM, Daniel P. Berrange wrote: > > > > > > On Wed, Dec 01, 2010 at 05:12:08PM -0700, Eric Blake wrote: > > > > > >> In testing <smbios mode='host'/>, I noticed a couple of problems. > > > > > >> First, qemu rejected the command line we gave it (invalid UUID); > > > > > >> ifixingthat showed that all other arguments were being given literal > > > > > >> "" which then made the guest smbios differ from the host. Second, > > > > > >> the qemu option -smbios type=1,family=string wasn't supported, which > > > > > >> lead to a spurious difference between host and guest. > > > > > >> > > > > > >> Meanwhile, qemu has a bug where '-smbios type=1,uuid=uuid' must parse > > > > > >> as a valid uuid, but is otherwise ignored. The current qemu.git code > > > > > >> base _only_ sets smbios uuid from the '-uuid uuid' argument. I've > > > > > >> filed a bug against the qemu folks asking whether this is intended (in > > > > > >> which case we have to modify libvirt to change the -uuid argument it > > > > > >> outputs when smbios is specified), or an oversight (hopefully the > > > > > >> latter, since it's still nice to correlate > > > > > >> /var/log/libvirt/qemu/....log with the XML uuid even when that differs > > > > > >> from the smbios uuid presented to the guest.) > > > > > > > > > > > > Hmm, I thought the UUID we were passing in was a host UUID, but > > > > > > on closer inspection the type=1 table is definitely intended to > > > > > > carry the guest UUID. As such it doesn't make sense to populate > > > > > > that with anything other than the '<uuid>' from the guest XML. > > > > > > A host UUID should live elsewhere in the SMBIOS tables, likely > > > > > > in the type2 or type3 blocks > > > > > > > > > > What does that mean to our XML? Should we reject XML files where both > > > > > domain/uuid and domain/sysinfo/system/entry/uuid exist, but differ? > > > > > Both elements are optional, so it's feasible to see a guest uuid in > > > > > either location. Meanwhile, I'm waiting on resolution to > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=659122 to see if qemu will > > > > > be patched to let us stick the host's uuid in block 2 (base board) or > > > > > block 3 (chassis), in which case, we'll need to expand our XML to > > > > > support that notion. > > > > > > > > > As I commented on the BZ use OEM strings type 11 smbios table to pass > > > > anything you want into a guest. > > > > > > > > > I've also discovered that with current qemu, if both '-uuid uuid' and > > > > > '-smbios type=1,uuid=uuid' are specified, then -uuid takes precedence; > > > > > but either one of the two in isolation serves to set smbios block 1 with > > > > > the guest's uuid. > > > > > > > > > I am surprised that libvirt still uses -uuid. > > > > > > SMBIOS tables are only setup on x86 QEMU binaries, doing fullvirt. > > > On non-x86, or QEMU used for Xen paravirt, the -uuid arg value > > > would be used in other ways unrelated to SMBIOS. Thus replacing > > > -uuid $UUID with -smbiios type=1,uuid=$UUID would be wrong. > > > > > What non-x86 platforms libvirt supports? With Xen use -uuid or whatever > > they support. With KVM use only smbios type=1,uuid=$UUID. There is not > > valid reason that I see to use both. But if you use both of them for some > > strange reason please make sure you provide the same value for both. > > libvirt aims to support any and all QEMU target architectures > not merely x86. There's no benefit to using -smbios type=1,uuid=$UUID > with KVM, over -uuid $UUID. So why do you use them both? Even more interesting question why do you use them both with different $UUID? If you do, do not complain that there should be some kind of order between them. > Changing it only for KVM would needlessly > complicate the code. > Doing things correctly is more important that simple code. And this is not related to KVM at all. You cannot expect qemu-sparc to work with qemu-x86 command line, so if you aim to support any and all qemu targets you should know how to build correct parameter list for any and all of them. -- Gleb. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list