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