> On Apr 12, 2017, at 1:22 PM, Marc-André Lureau <marcandre.lur...@gmail.com> > wrote: > > Hi > > On Thu, Apr 13, 2017 at 12:17 AM Ben Warren <b...@skyportsystems.com > <mailto:b...@skyportsystems.com>> wrote: >> On Apr 12, 2017, at 1:06 PM, Marc-André Lureau <marcandre.lur...@gmail.com >> <mailto:marcandre.lur...@gmail.com>> wrote: >> >> +Device Usage: >> +------------- >> + >> +The device has one property, which may be only be set using the command >> line: >> + >> + guid - sets the value of the GUID. A special value "auto" instructs >> + QEMU to generate a new random GUID. >> + >> +For example: >> + >> + QEMU -device vmgenid,guid="324e6eaf-d1d1-4bf6-bf41-b9bb6c91fb87" >> + QEMU -device vmgenid,guid=auto >> >> The default will keep uuid to null, should it be documented? Wouldn't it >> make sense to default to auto? > > There is no default - you have to supply a value. It’s up to whatever > software is managing VM lifecycle to decide what value to pass in. Always > setting to ‘auto’ will cause a lot of churn within Windows that may or may > not be acceptable to your use case. > > > Why would you have a vmgenid device if it's always null? Does that please > some windows use-cases as well? > I don’t get what you mean by this. What device is always null? Either the device is instantiated or it isn’t. If not there, Windows will not find a device and I don’t know how derived objects (Invocation ID, etc.) are handled. >> >> +The property may be queried via QMP/HMP: >> + >> + (QEMU) query-vm-generation-id >> + {"return": {"guid": "324e6eaf-d1d1-4bf6-bf41-b9bb6c91fb87"}} >> + >> +Setting of this parameter is intentionally left out from the QMP/HMP >> +interfaces. There are no known use cases for changing the GUID once QEMU is >> +running, and adding this capability would greatly increase the complexity. >> >> Is this supposed to be not permitted? >> >> { "execute": "qom-set", "arguments": { "path": >> "/machine/peripheral-anon/device[1]", "property": "guid", "value": "auto" } } >> >> Is there any linux kernel support being worked on? > > This isn’t really relevant to the Linux kernel, at least in any way I can > think of. What did you have in mind? > > Testing, but apparently we do have RFE for RHEL as Laszlo pointed out. OK, so you mean a guest driver. I do have one that needs work to go upstream, but has been helpful to me in testing. https://github.com/ben-skyportsystems/vmgenid-test <https://github.com/ben-skyportsystems/vmgenid-test>
> > Thanks > -- > Marc-André Lureau