Qemu machine types not changed on upgrade

john.r.moser at gmail.com john.r.moser at gmail.com
Sat Oct 22 01:02:44 UTC 2016

Hi all.

I've encountered some issues with Qemu machine types on upgrades. 
There has been some discussion about this in the past, e.g. 


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

 * 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 part is important.  I'm not sure it's true; from what I can
tell, the machine is wholly an .xml file and some disk images when it's
not running and not suspended.

When upgrading to 16.04, my VMs kept the type "pc-i440fx-vivid".  This
had the unpleasant implication of breaking them:  after rebooting into
16.04, virt-manager couldn't start the machine because that type is

This is apparently a common issue, and 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.

>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.

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.

Any thoughts?

More information about the ubuntu-server mailing list