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 <b...@skyportsystems.com> wrote:
>
> On Apr 12, 2017, at 1:47 PM, Marc-André Lureau <
> marcandre.lur...@gmail.com> wrote:
>
> Hi
>
> On Thu, Apr 13, 2017 at 12:25 AM Ben Warren <b...@skyportsystems.com>
> wrote:
>
> 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> wrote:
>
> On Apr 12, 2017, at 1:06 PM, Marc-André Lureau <
> 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.
>
>
> 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
