On 04/12/17 22:06, Marc-André Lureau wrote:
> On Thu, Mar 2, 2017 at 10:22 AM Michael S. Tsirkin <m...@redhat.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?

I guess it might.

> 
> 
>> +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" }
> }

I don't know if qom-set can be disabled for individual devices / device
properties. Either way, setting a new GUID for VMGENID will definitely
take custom code.

> Is there any linux kernel support being worked on?

There's an RHBZ for it (alias "vmgenid-kernel"):

https://bugzilla.redhat.com/show_bug.cgi?id=1159983

(It is private because RHBZs for the kernel component are private by
default.)

Thanks
Laszlo

Reply via email to