Re: [libvirt] [PATCH 0/2] smbios fixes
On Thu, Dec 02, 2010 at 08:12:23PM +, 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 +, 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/2] smbios fixes
On 12/03/2010 02:50 AM, Gleb Natapov wrote: I am surprised that libvirt still uses -uuid. Why? It still works, and it's backwards compatible even to older qemu where -smbios wasn't supported. It's actually harder to omit -uuid and use only -smbios, after first guaranteeing that -smbios is supported, than it is blindly use -uuid. And since -uuid may have more implications than just the -smbios table, whereas -smbios should not affect anything except the smbios table, it makes sense to continue to use -uuid for any of those other implications. 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. There's the real question. We use both as of libvirt 0.8.6 because we added the new XML for sysinfo type='smbios'.../sysinfoossmbios mode='sysinfo'//os, where sysinfo provides the argument to pass to qemu's -smbios argument. However, I agree with your assessment that -uuid and -smbios type=1,uuid= should never differ, so I've proposed an updated patch series to guarantee that behavior (particularly patch 4/5): https://www.redhat.com/archives/libvir-list/2010-December/msg00237.html As for whether it is useful to pass the host UUID to the client through smbios, I agree with you that 1. it is still up in the air as to whether that is a decent design, or whether something better should be dreamed up, and 2. it would have to be done through smbios block 11 (OEM strings) and NOT by changing the guest's uuid (whether that uuid was supplied by uuid, by sysinfo, or identically in both locations, from the libvirt XML). But both of those points are part of the bigger picture, and shouldn't affect whether my patch series is accepted for fixing up current bugs in libvirt smbios handling (although it may imply future libvirt patches to start creating an appropriate binary file for use with -smbios binary=file for passing the host uuid as an oem string). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/2] smbios fixes
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 Daniel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/2] smbios fixes
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. 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. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/2] smbios fixes
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. -- Gleb. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/2] smbios fixes
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. Regards, Daniel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/2] smbios fixes
On Thu, Dec 02, 2010 at 07:56:03PM +, 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. -- Gleb. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/2] smbios fixes
On Thu, Dec 02, 2010 at 10:04:59PM +0200, Gleb Natapov wrote: On Thu, Dec 02, 2010 at 07:56:03PM +, 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. Changing it only for KVM would needlessly complicate the code. Daniel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 0/2] smbios fixes
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.) Eric Blake (2): qemu: avoid adding in smbios arguments smbios: support system family docs/schemas/domain.rng |1 + src/conf/domain_conf.c |9 +++- src/qemu/qemu_conf.c| 26 +- src/util/sysinfo.c |7 ++ src/util/sysinfo.h |1 + tests/qemuxml2argvdata/qemuxml2argv-smbios.args |2 +- tests/qemuxml2argvdata/qemuxml2argv-smbios.xml |2 + 7 files changed, 35 insertions(+), 13 deletions(-) -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
