| Message ID | 20181108141944.15769-1-minyard@acm.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | ipmi: Allow UUID to be set for a BMC | expand |
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.
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