[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PULL 02/15] docs: VM Generation ID device description
From: |
Ben Warren |
Subject: |
Re: [Qemu-devel] [PULL 02/15] docs: VM Generation ID device description |
Date: |
Wed, 12 Apr 2017 13:25:42 -0700 |
> 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
> <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.
>>
>> +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
> --
> Marc-André Lureau
- Re: [Qemu-devel] [PULL 02/15] docs: VM Generation ID device description, Marc-André Lureau, 2017/04/12
- Re: [Qemu-devel] [PULL 02/15] docs: VM Generation ID device description, Laszlo Ersek, 2017/04/12
- Re: [Qemu-devel] [PULL 02/15] docs: VM Generation ID device description, Ben Warren, 2017/04/12
- Re: [Qemu-devel] [PULL 02/15] docs: VM Generation ID device description, Marc-André Lureau, 2017/04/12
- Re: [Qemu-devel] [PULL 02/15] docs: VM Generation ID device description,
Ben Warren <=
- Re: [Qemu-devel] [PULL 02/15] docs: VM Generation ID device description, Marc-André Lureau, 2017/04/12
- Re: [Qemu-devel] [PULL 02/15] docs: VM Generation ID device description, Ben Warren, 2017/04/12
- Re: [Qemu-devel] [PULL 02/15] docs: VM Generation ID device description, Marc-André Lureau, 2017/04/12
- Re: [Qemu-devel] [PULL 02/15] docs: VM Generation ID device description, Michael S. Tsirkin, 2017/04/12
- Re: [Qemu-devel] [PULL 02/15] docs: VM Generation ID device description, Marc-André Lureau, 2017/04/13
Re: [Qemu-devel] [PULL 02/15] docs: VM Generation ID device description, Michael S. Tsirkin, 2017/04/12