Qemu machine types not changed on upgrade

[Christian Ehrhardt]

On Sat, Oct 22, 2016 at 3:02 AM, <john.r.moser at gmail.com> wrote:

> I've encountered some issues with Qemu machine types on upgrades.
>
There has been some discussion about this in the past, e.g.
>
> https://lists.ubuntu.com/archives/ubuntu-server/2016-September/007411.h
> tml
>


Hi John,
thanks for your writeup.
Overall I agree and I think it can become another change to make the
Qemu/KVM better for the Ubuntu Community.


> and much of that is stuff I don't grasp.  As far as I can tell:
>

I guess nobody does completely :-), but I'll try to go into some details
below to help.


>  * The machine type is critical for migration, and must uniquely-
>    identify the capabilities of the machine;
>
>  * That doesn't matter when the machine is off.
>

That second one is unfortunately only partially true.
It obviously doesn't matter "while" it is off, but it matters once you
restart.

Essentially a change in a machine type - when going forward to a newer
version - can be considered like taking your computer and refreshing all
components with the most recent ones off the shelf.
I hope nobody bashes me for that comparison, but I think that is what makes
the most sense to make it more understandable.

That more or less has the same implications.
Of course you might be (and often are) good and your drivers just work with
the new features, firmware and such that are provided.
Linux is notoriously good at tolerating most of the changes compared to
other OSes, but you still can face issues with that.
So you might just as well be the unlucky one where a new cpu feature, a
changed network nic ram size or any such attributes break your old
configuration.

That is the reason that changing machine types on upgrade was always a
manual task.
It depends so much on your workload and guest bits that it can never be
fully automated.

[...]

 several people discussing it
> online simply state that Ubuntu and RHEL both customize the PC types as
> another arbitrary way to be different, and that "pc" always works.
>

I'd like to avoid to go down this part of the discussion if possible.
The decisions in the past to do so (for all distributions) where based on
cases back then and I'd not so much question that.
I know most of the people that did that cross distribution and I can tell
you that I never heard of any conspiracy or product-binding plan being
involved.
But as I said, I should and want try to stay away from that part of the
discussion ...


> From what I can tell, there's no provision in virt-manager or libvirtd
> to automatically upgrade a machine.  If you install virt-manager and
> build VMs, it's easy and it works; and because you know nothing about
> how it works internally, it will eventually break 2-3 distribution
> upgrades later when the machine type is no longer supported.  Then
> it'll give some arcane message about machine types not being supported.
>

Yes, I agree that this is a pain we should look forward to address.

For quite a while now I thought it might be time to be more vocal about
"you should upgrade your machine type".
Essentially this change is also a way to get in latest fixes.

Kudos to Suse on this case, I must admit their statement pretty much covers
my opinion =>
https://www.suse.com/documentation/sles-12/book_virt/data/sec_libvirt_config_mahcinetype_virsh.html


> virt-manager should at least ask about starting an OFF machine as a
> supported machine, i.e. pc-i440fx-vivid becomes pc-i440fx-*, or pc-* as
> a last-ditch effort.  It would also be nice if the interface could
> allow upgrading the machine type, or set configuration to automatically
> upgrade the machine type to the latest compatible type so that things
> just don't break that way.
>
> I get that this means a newly-upgraded 16.04 member of a VM cluster
> might suddenly not be able to migrate any machines from itself to a
> 14.04 member of the same cluster.  Perhaps it shouldn't be a default
> option.  Perhaps the target machine version should be configurable
> (e.g. configure libvirtd to automatically upgrade all machines as far
> as pc-i440fx-vivid, but no higher--persist this configuration after do-
> release-upgrade, until the admin changes it and all machines upgrade on
> migration or restart).
>
> I just think it's at least a good idea to say, "Hey, this machine's
> off, and I can't turn it on!  It's configured for an old or unknown
> machine type.  Want to update its configuration?" and the user says
> "Yes" and it just works.  Otherwise you have to dig into the XML
> configuration or run some arcane configuration commands or some such;
> I'm still not sure how it all works.
>

I like your examples.
For the reasons I outlined before it can never be an auto-upgrade as that
could mean way more losses to people using it.
Imagine that ever causes some sort of data corruption - being a manual task
allows everybody to take this step as a conscious decision.

But that doesn't mean we can't do anything and as I said I like your
examples, so what I'd suggest is:
- we open a bug for it to track the work on it, currently I'd define the
scope to this
  - add documentation to
https://help.ubuntu.com/lts/serverguide/libvirt.html#libvirt-management
(could use some update/extension anyway I think)
  - on qemu/libvirt upgrade scan for old-now-unsupported types and in case
prompt the user to follow the documentation to consider updating as
suitable for him
  - not sure on virt-manager changes for that yet, but we can do and
discuss that step by step

I'd handle details how/where things should be changes in the bug(s), but
before opening would like to wait if anything else on this discussion comes
up for about this week.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-server/attachments/20161024/f5832c27/attachment.html>