The code was using the qemu UUID for the BMC.  But that's really
not a good method.  In general, you don't want the GUID to change
when you migrate, and you want the GUID to be the same between
invocations of qemu (if you have a GUID).

Plus, if you have multiple BMCs, they need to have different
GUIDs or the host code cannot tell them apart.  I'm not sure
anyone really uses multiple BMCs, but I do a lot of testing
with that scenario.

This change lets the user set the GUID on the command line, and
if the GUID is not set return an error for the GUID fetch command.
This maps better to how IPMI should work.

This change relies on the UUID being set to all zeros to know that
it is not set.  This is not optimal, perhaps, but an all zero
UUID isn't valid (it's the Nil UUID), so it should be ok.

On Thu, Nov 08, 2018 at 08:19:42AM -0600, minyard@acm.org wrote:
> The code was using the qemu UUID for the BMC.  But that's really
> not a good method.  In general, you don't want the GUID to change
> when you migrate, and you want the GUID to be the same between
> invocations of qemu (if you have a GUID).

Hrm.  Generally the qemu UUID should remain the same across a
migration too, and I think that will be the case if using libvirt.
Maybe not if running qemu by hand and not specifying the uuid on the
command line.

I don't really have an objection to allowing the BMC's id to be
explicitly controlled, but the rationale above seems a bit
disingenuous.

> Plus, if you have multiple BMCs, they need to have different
> GUIDs or the host code cannot tell them apart.  I'm not sure
> anyone really uses multiple BMCs, but I do a lot of testing
> with that scenario.
> 
> This change lets the user set the GUID on the command line, and
> if the GUID is not set return an error for the GUID fetch command.
> This maps better to how IPMI should work.
> 
> This change relies on the UUID being set to all zeros to know that
> it is not set.  This is not optimal, perhaps, but an all zero
> UUID isn't valid (it's the Nil UUID), so it should be ok.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

On 11/8/18 5:22 PM, David Gibson wrote:
> On Thu, Nov 08, 2018 at 08:19:42AM -0600, minyard@acm.org wrote:
>> The code was using the qemu UUID for the BMC.  But that's really
>> not a good method.  In general, you don't want the GUID to change
>> when you migrate, and you want the GUID to be the same between
>> invocations of qemu (if you have a GUID).
> Hrm.  Generally the qemu UUID should remain the same across a
> migration too, and I think that will be the case if using libvirt.
> Maybe not if running qemu by hand and not specifying the uuid on the
> command line.
>
> I don't really have an objection to allowing the BMC's id to be
> explicitly controlled, but the rationale above seems a bit
> disingenuous.


I'm not sure about migration.  I suppose it could be migrated, but I
would consider the BMC part of the hardware that needs to be the
same on both sides.  It's a fuzzy line, I suppose.  The qemu UUID
is migrated, so I suppose that's not an issue.

Controlling it explicitly is important for some testing I do, and might
be for other people at some point in time, if you are trying to
emulate something specific.  And when re-invoking qemu, you
might want to keep it the same to avoid confusing software.

The big question for you is the lack of a GUID if it's not supplied.
With this change, the get GUID command will return a "command
not supported" error if the GUID is not supplied.

Thanks,

-corey

>> Plus, if you have multiple BMCs, they need to have different
>> GUIDs or the host code cannot tell them apart.  I'm not sure
>> anyone really uses multiple BMCs, but I do a lot of testing
>> with that scenario.
>>
>> This change lets the user set the GUID on the command line, and
>> if the GUID is not set return an error for the GUID fetch command.
>> This maps better to how IPMI should work.
>>
>> This change relies on the UUID being set to all zeros to know that
>> it is not set.  This is not optimal, perhaps, but an all zero
>> UUID isn't valid (it's the Nil UUID), so it should be ok.

On 09/11/18 14:33, Corey Minyard wrote:
> On 11/8/18 5:22 PM, David Gibson wrote:
> I'm not sure about migration.  I suppose it could be migrated, but I
> would consider the BMC part of the hardware that needs to be the
> same on both sides.  It's a fuzzy line, I suppose.  The qemu UUID
> is migrated, so I suppose that's not an issue.
> 
> Controlling it explicitly is important for some testing I do, and might
> be for other people at some point in time, if you are trying to
> emulate something specific.  And when re-invoking qemu, you
> might want to keep it the same to avoid confusing software.

I don't understand, do you need it to be different from the dmicode
UUID?  On real hardware are they the same or different?

Thanks,

Paolo

On 12/6/18 3:10 PM, Paolo Bonzini wrote:
> On 09/11/18 14:33, Corey Minyard wrote:
>> On 11/8/18 5:22 PM, David Gibson wrote:
>> I'm not sure about migration.  I suppose it could be migrated, but I
>> would consider the BMC part of the hardware that needs to be the
>> same on both sides.  It's a fuzzy line, I suppose.  The qemu UUID
>> is migrated, so I suppose that's not an issue.
>>
>> Controlling it explicitly is important for some testing I do, and might
>> be for other people at some point in time, if you are trying to
>> emulate something specific.  And when re-invoking qemu, you
>> might want to keep it the same to avoid confusing software.
> I don't understand, do you need it to be different from the dmicode
> UUID?  On real hardware are they the same or different?

They are different on real hardware, and software that uses IPMI
can expect that it doesn't change unless the BMC changes.  It's
not used that often, though.

It's often used to know that you are talking to the same BMC if
you have multiple connections (like a local connection and one
coming in over the LAN).

I primarily need it for testing things in the Linux IPMI driver,
identifying if BMCs connections are the same or not.

-corey

> Thanks,
>
> Paolo

On 06/12/18 22:27, Corey Minyard wrote:
> On 12/6/18 3:10 PM, Paolo Bonzini wrote:
>> On 09/11/18 14:33, Corey Minyard wrote:
>>> On 11/8/18 5:22 PM, David Gibson wrote:
>>> I'm not sure about migration.  I suppose it could be migrated, but I
>>> would consider the BMC part of the hardware that needs to be the
>>> same on both sides.  It's a fuzzy line, I suppose.  The qemu UUID
>>> is migrated, so I suppose that's not an issue.
>>>
>>> Controlling it explicitly is important for some testing I do, and might
>>> be for other people at some point in time, if you are trying to
>>> emulate something specific.  And when re-invoking qemu, you
>>> might want to keep it the same to avoid confusing software.
>> I don't understand, do you need it to be different from the dmicode
>> UUID?  On real hardware are they the same or different?
> 
> They are different on real hardware, and software that uses IPMI
> can expect that it doesn't change unless the BMC changes.

You can say the latter of the dmidecode UUID too, it's not supposed to
change.  However, if they are different in real hardware they should be
different in QEMU too.  Or at least it should be possible to make them
different. :)

I guess it's up to you whether the default should be qemu_uuid or no
support for the get UUID command.

Thanks,

Paolo