[Qemu-devel] [PATCH] qemu-options: document existance of versioned machine types

Daniel P. Berrange posted 1 patch 6 years, 8 months ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20170725141041.1195-1-berrange@redhat.com
Test FreeBSD passed
Test checkpatch passed
Test s390x passed
qemu-options.hx | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
[Qemu-devel] [PATCH] qemu-options: document existance of versioned machine types
Posted by Daniel P. Berrange 6 years, 8 months ago
The -machine docs did not explain what the versioned machine
types are for, nor that they'll be maintained across
releases.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
---
 qemu-options.hx | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index 746b5fa75d..9f6e2adfff 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -49,7 +49,20 @@ STEXI
 @item -machine [type=]@var{name}[,prop=@var{value}[,...]]
 @findex -machine
 Select the emulated machine by @var{name}. Use @code{-machine help} to list
-available machines. Supported machine properties are:
+available machines.
+
+For architectures which aim to support live migration compatibility
+across releases, each release will introduce a new versioned machine
+type. For example, the 2.8.0 release introduced machine types
+``pc-i440fx-2.8'' and ``pc-q35-2.8'' for the x86_64/i686 architectures.
+
+To allow live migration of guests from QEMU version 2.8.0, to QEMU
+version 2.9.0, the 2.9.0 version must support the ``pc-i440fx-2.8''
+and ``pc-q35-2.8'' machines too. To allow users live migrating VMs
+to skip multiple intermediate releases when upgrading, new releases
+of QEMU will support machine types from many previous versions.
+
+Supported machine properties are:
 @table @option
 @item accel=@var{accels1}[:@var{accels2}[:...]]
 This is used to enable an accelerator. Depending on the target architecture,
-- 
2.13.3


Re: [Qemu-devel] [PATCH] qemu-options: document existance of versioned machine types
Posted by John Snow 6 years, 8 months ago

On 07/25/2017 10:10 AM, Daniel P. Berrange wrote:
> The -machine docs did not explain what the versioned machine
> types are for, nor that they'll be maintained across
> releases.
> 
> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
> ---
>   qemu-options.hx | 15 ++++++++++++++-
>   1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 746b5fa75d..9f6e2adfff 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -49,7 +49,20 @@ STEXI
>   @item -machine [type=]@var{name}[,prop=@var{value}[,...]]
>   @findex -machine
>   Select the emulated machine by @var{name}. Use @code{-machine help} to list
> -available machines. Supported machine properties are:
> +available machines.
> +
> +For architectures which aim to support live migration compatibility
> +across releases, each release will introduce a new versioned machine
> +type. For example, the 2.8.0 release introduced machine types
> +``pc-i440fx-2.8'' and ``pc-q35-2.8'' for the x86_64/i686 architectures.
> +
> +To allow live migration of guests from QEMU version 2.8.0, to QEMU
> +version 2.9.0, the 2.9.0 version must support the ``pc-i440fx-2.8''
> +and ``pc-q35-2.8'' machines too. To allow users live migrating VMs
> +to skip multiple intermediate releases when upgrading, new releases
> +of QEMU will support machine types from many previous versions.
> +
> +Supported machine properties are:
>   @table @option
>   @item accel=@var{accels1}[:@var{accels2}[:...]]
>   This is used to enable an accelerator. Depending on the target architecture,
> 

Seems like an improvement to me, but do we have any formal policy on how 
long we support said machine types? The new wording prompts that question.

Reviewed-by: John Snow <jsnow@redhat.com>


Re: [Qemu-devel] [PATCH] qemu-options: document existance of versioned machine types
Posted by Paolo Bonzini 6 years, 8 months ago
> 
> On 07/25/2017 10:10 AM, Daniel P. Berrange wrote:
> > The -machine docs did not explain what the versioned machine
> > types are for, nor that they'll be maintained across
> > releases.
> > 
> > Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
> > ---
> >   qemu-options.hx | 15 ++++++++++++++-
> >   1 file changed, 14 insertions(+), 1 deletion(-)
> > 
> > diff --git a/qemu-options.hx b/qemu-options.hx
> > index 746b5fa75d..9f6e2adfff 100644
> > --- a/qemu-options.hx
> > +++ b/qemu-options.hx
> > @@ -49,7 +49,20 @@ STEXI
> >   @item -machine [type=]@var{name}[,prop=@var{value}[,...]]
> >   @findex -machine
> >   Select the emulated machine by @var{name}. Use @code{-machine help} to
> >   list
> > -available machines. Supported machine properties are:
> > +available machines.
> > +
> > +For architectures which aim to support live migration compatibility
> > +across releases, each release will introduce a new versioned machine
> > +type. For example, the 2.8.0 release introduced machine types
> > +``pc-i440fx-2.8'' and ``pc-q35-2.8'' for the x86_64/i686 architectures.
> 
> Seems like an improvement to me, but do we have any formal policy on how
> long we support said machine types? The new wording prompts that question.

Forever, and ever...

Paolo

Re: [Qemu-devel] [PATCH] qemu-options: document existance of versioned machine types
Posted by Daniel P. Berrange 6 years, 8 months ago
On Tue, Jul 25, 2017 at 01:46:23PM -0400, John Snow wrote:
> 
> 
> On 07/25/2017 10:10 AM, Daniel P. Berrange wrote:
> > The -machine docs did not explain what the versioned machine
> > types are for, nor that they'll be maintained across
> > releases.
> > 
> > Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
> > ---
> >   qemu-options.hx | 15 ++++++++++++++-
> >   1 file changed, 14 insertions(+), 1 deletion(-)
> > 
> > diff --git a/qemu-options.hx b/qemu-options.hx
> > index 746b5fa75d..9f6e2adfff 100644
> > --- a/qemu-options.hx
> > +++ b/qemu-options.hx
> > @@ -49,7 +49,20 @@ STEXI
> >   @item -machine [type=]@var{name}[,prop=@var{value}[,...]]
> >   @findex -machine
> >   Select the emulated machine by @var{name}. Use @code{-machine help} to list
> > -available machines. Supported machine properties are:
> > +available machines.
> > +
> > +For architectures which aim to support live migration compatibility
> > +across releases, each release will introduce a new versioned machine
> > +type. For example, the 2.8.0 release introduced machine types
> > +``pc-i440fx-2.8'' and ``pc-q35-2.8'' for the x86_64/i686 architectures.
> > +
> > +To allow live migration of guests from QEMU version 2.8.0, to QEMU
> > +version 2.9.0, the 2.9.0 version must support the ``pc-i440fx-2.8''
> > +and ``pc-q35-2.8'' machines too. To allow users live migrating VMs
> > +to skip multiple intermediate releases when upgrading, new releases
> > +of QEMU will support machine types from many previous versions.
> > +
> > +Supported machine properties are:
> >   @table @option
> >   @item accel=@var{accels1}[:@var{accels2}[:...]]
> >   This is used to enable an accelerator. Depending on the target architecture,
> > 
> 
> Seems like an improvement to me, but do we have any formal policy on how
> long we support said machine types? The new wording prompts that question.

I wasn't going to mention that in this patch, to avoid delay on getting it
merged. I was going to send a further patch that makes it explicit that we
will never delete machine types for as long as any active QEMU contributor
has need for them in downstream version they maintain

> Reviewed-by: John Snow <jsnow@redhat.com>

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH] qemu-options: document existance of versioned machine types
Posted by John Snow 6 years, 8 months ago

On 07/26/2017 04:07 AM, Daniel P. Berrange wrote:
> On Tue, Jul 25, 2017 at 01:46:23PM -0400, John Snow wrote:
>>
>>
>> On 07/25/2017 10:10 AM, Daniel P. Berrange wrote:
>>> The -machine docs did not explain what the versioned machine
>>> types are for, nor that they'll be maintained across
>>> releases.
>>>
>>> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
>>> ---
>>>    qemu-options.hx | 15 ++++++++++++++-
>>>    1 file changed, 14 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/qemu-options.hx b/qemu-options.hx
>>> index 746b5fa75d..9f6e2adfff 100644
>>> --- a/qemu-options.hx
>>> +++ b/qemu-options.hx
>>> @@ -49,7 +49,20 @@ STEXI
>>>    @item -machine [type=]@var{name}[,prop=@var{value}[,...]]
>>>    @findex -machine
>>>    Select the emulated machine by @var{name}. Use @code{-machine help} to list
>>> -available machines. Supported machine properties are:
>>> +available machines.
>>> +
>>> +For architectures which aim to support live migration compatibility
>>> +across releases, each release will introduce a new versioned machine
>>> +type. For example, the 2.8.0 release introduced machine types
>>> +``pc-i440fx-2.8'' and ``pc-q35-2.8'' for the x86_64/i686 architectures.
>>> +
>>> +To allow live migration of guests from QEMU version 2.8.0, to QEMU
>>> +version 2.9.0, the 2.9.0 version must support the ``pc-i440fx-2.8''
>>> +and ``pc-q35-2.8'' machines too. To allow users live migrating VMs
>>> +to skip multiple intermediate releases when upgrading, new releases
>>> +of QEMU will support machine types from many previous versions.
>>> +
>>> +Supported machine properties are:
>>>    @table @option
>>>    @item accel=@var{accels1}[:@var{accels2}[:...]]
>>>    This is used to enable an accelerator. Depending on the target architecture,
>>>
>>
>> Seems like an improvement to me, but do we have any formal policy on how
>> long we support said machine types? The new wording prompts that question.
> 
> I wasn't going to mention that in this patch, to avoid delay on getting it
> merged. I was going to send a further patch that makes it explicit that we
> will never delete machine types for as long as any active QEMU contributor
> has need for them in downstream version they maintain
> 
>> Reviewed-by: John Snow <jsnow@redhat.com>
> 
> Regards,
> Daniel
> 

OK, just asking. I agree we don't need to delay this patch if you want 
it in for 2.10, which is a worthwhile and good thing.

Thanks!

--js