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

[Michael S. Tsirkin]

On Wed, Apr 12, 2017 at 09:17:12PM +0000, Marc-André Lureau wrote:
> Hi
> 
> On Thu, Apr 13, 2017 at 1:03 AM Ben Warren <address@hidden> wrote:
> 
>         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>
>         wrote:
> 
>                 On Apr 12, 2017, at 1:22 PM, Marc-André Lureau <
>                 address@hidden> wrote:
> 
>                 Hi
> 
>                 On Thu, Apr 13, 2017 at 12:17 AM Ben Warren <
>                 address@hidden> wrote:
> 
>                         On Apr 12, 2017, at 1:06 PM, Marc-André Lureau <
>                         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. 
> 
> 
> Not necessarily a bug, if the guid can be changed when starting a "new" VM,
> which I think should work.

I think spec does not allow for a special "invalid" guid value ATM.


> However, I didn't manage to get your driver noticing the acpi event. I tried 
> to
> migrate/save & restore, and no vmgenid_notify kernel messages came out, nor
> notices got incremented. How did you test it?
>  
> 
>     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.
> 
> 
> 
> 
> I start to understand better the use case and how the device should be used.
>  
> thanks again
> 
> 
> 
>                          
> 
>                             +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
> 
> 
>         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
> 
> --
> Marc-André Lureau