Re: [Qemu-devel] [PULL 02/15] docs: VM Generation ID device description

[Ben Warren]

> On Apr 12, 2017, at 1:47 PM, Marc-André Lureau <address@hidden> wrote:
> 
> Hi
> 
> On Thu, Apr 13, 2017 at 12:25 AM Ben Warren <address@hidden 
> <mailto:address@hidden>> wrote:
>> On Apr 12, 2017, at 1:22 PM, Marc-André Lureau <address@hidden 
>> <mailto:address@hidden>> wrote:
>> 
>> Hi
>> 
>> On Thu, Apr 13, 2017 at 12:17 AM Ben Warren <address@hidden 
>> <mailto:address@hidden>> wrote:
>>> On Apr 12, 2017, at 1:06 PM, Marc-André Lureau <address@hidden 
>>> <mailto:address@hidden>> 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.
> 
> If you start a VM without specifying guid argument, you'll always have a 
> genid null uuid, event after a migration (this could have been handled by 
> qemu without requiring management layer, no?). I don't understand why auto 
> would create more churn than what the management layer would do by setting 
> new uuid for each VM started. Could you explain?
> 
Looks like there’s a bug.  GUID should be a mandatory parameter.  As for the 
churn, I’ll give you one example.  If an Active Directory Domain Controller 
(ADDC) detects a change in VM Generation ID, it takes this to mean that the VM 
has been rolled back in time, and so its replication sequence numbers are 
“dirty”.  This has the effect of causing the Domain controller to perform a 
full “pull replication” with other ADDCs.  In large deployments this can be 
costly.  VM Generation ID is used by other applications besides AD.
> 
>>>  
>>> +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, that's exactly what I was looking for :) 

Good.  I wish I had the time to integrate this upstream, but it’s one of those 
things that is good enough, and so will have to wait for another time.
> -- 
> Marc-André Lureau