qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Change virtio-console to PCI_CLASS_SERIAL_OTHER


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH] Change virtio-console to PCI_CLASS_SERIAL_OTHER
Date: Thu, 28 May 2009 08:19:25 -0500
User-agent: Thunderbird 2.0.0.21 (X11/20090409)

Daniel P. Berrange wrote:
> On Thu, May 28, 2009 at 01:53:49PM +0100, Paul Brook wrote:
>   
>> On Wednesday 27 May 2009, Mark McLoughlin wrote:
>>     
>>> On Wed, 2009-05-27 at 09:21 -0500, Anthony Liguori wrote:
>>>       
>>>> We need a mechanism to toggle this for both this and virtio-blk.  The
>>>> reason a toggle is needed is so that 0.11 can create the same device
>>>> model as 0.10.
>>>>         
>>> Okay, so the scenario is:
>>>
>>>   - 0.10 guest running on source machine
>>>
>>>   - migrate to dest machine running 0.11
>>>
>>>   - the device model cannot change or the guest OS will get confused
>>>       
>> IMHO think the only sane response is "don't do that". Trying to support 
>> migration between different qemu versions just isn't worth the pain.
>>     
>
> I think that further more, we shouldn't make a change like altering
> the PCI device class in the stable branch, only in the unstable 
> branch. If we restrict the stable branch to bug fixes, then it ought
> to be (more?) practical to support save under 0.10 and restore under
> 0.11, without needing to support the hard problem of save under 0.10
> and restore under 1.00 (or whatever next major release branch is)
>   

This is not a save/restore issue.  PCI config will be saved in the image
so everything is fine until you shut a VM down.

The problem is that the device model a guest sees is an ABI.  If we
change the ABI between versions, the guest make break.  What I'm
proposing is that while we can change the default guest ABI between
versions, we must provide a way to recreate older forms of the guest ABI.

A good example of guests breaking is Windows activation failing.  It has
happened more than once that changes in QEMU cause Windows guests to
force reactivation.  In more extreme instances, a guest may break that
used to work before.

Regards,

Anthony Liguori

> Regards,
> Daniel
>   





reply via email to

[Prev in Thread] Current Thread [Next in Thread]