<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Oct 22, 2016 at 3:02 AM,  <span dir="ltr"><<a href="mailto:john.r.moser@gmail.com" target="_blank">john.r.moser@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I've encountered some issues with Qemu machine types on upgrades.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
There has been some discussion about this in the past, e.g.<br>
<br>
<a href="https://lists.ubuntu.com/archives/ubuntu-server/2016-September/007411.h
tml" rel="noreferrer" target="_blank">https://lists.ubuntu.com/<wbr>archives/ubuntu-server/2016-<wbr>September/007411.h<br>
tml</a><br></blockquote><div><br></div><div><div><br class="gmail-Apple-interchange-newline">Hi John,</div><div>thanks for your writeup.</div><div>Overall I agree and I think it can become another change to make the Qemu/KVM better for the Ubuntu Community.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
and much of that is stuff I don't grasp.  As far as I can tell:<br></blockquote><div><br></div><div>I guess nobody does completely :-), but I'll try to go into some details below to help.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
 * The machine type is critical for migration, and must uniquely-<br>
   identify the capabilities of the machine;<br>
<br>
 * That doesn't matter when the machine is off.<br></blockquote><div><br></div><div>That second one is unfortunately only partially true.</div><div>It obviously doesn't matter "while" it is off, but it matters once you restart.</div><div><br></div><div>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.</div><div>I hope nobody bashes me for that comparison, but I think that is what makes the most sense to make it more understandable.</div><div><br></div><div>That more or less has the same implications.</div><div>Of course you might be (and often are) good and your drivers just work with the new features, firmware and such that are provided.</div><div>Linux is notoriously good at tolerating most of the changes compared to other OSes, but you still can face issues with that.</div><div>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.</div><div><br></div><div>That is the reason that changing machine types on upgrade was always a manual task.</div><div>It depends so much on your workload and guest bits that it can never be fully automated.</div><div><br></div><div>[...]</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> several people discussing it<br>
online simply state that Ubuntu and RHEL both customize the PC types as<br>
another arbitrary way to be different, and that "pc" always works.<br></blockquote><div><br></div><div>I'd like to avoid to go down this part of the discussion if possible.</div><div>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.</div><div>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.</div><div>But as I said, I should and want try to stay away from that part of the discussion ...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>From what I can tell, there's no provision in virt-manager or libvirtd<br>
to automatically upgrade a machine.  If you install virt-manager and<br>
build VMs, it's easy and it works; and because you know nothing about<br>
how it works internally, it will eventually break 2-3 distribution<br>
upgrades later when the machine type is no longer supported.  Then<br>
it'll give some arcane message about machine types not being supported.<br></blockquote><div><br></div><div>Yes, I agree that this is a pain we should look forward to address.</div><div><br></div><div>For quite a while now I thought it might be time to be more vocal about "you should upgrade your machine type".</div><div>Essentially this change is also a way to get in latest fixes.</div><div><br></div><div>Kudos to Suse on this case, I must admit their statement pretty much covers my opinion => <a href="https://www.suse.com/documentation/sles-12/book_virt/data/sec_libvirt_config_mahcinetype_virsh.html">https://www.suse.com/documentation/sles-12/book_virt/data/sec_libvirt_config_mahcinetype_virsh.html</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
virt-manager should at least ask about starting an OFF machine as a<br>
supported machine, i.e. pc-i440fx-vivid becomes pc-i440fx-*, or pc-* as<br>
a last-ditch effort.  It would also be nice if the interface could<br>
allow upgrading the machine type, or set configuration to automatically<br>
upgrade the machine type to the latest compatible type so that things<br>
just don't break that way.<br>
<br>
I get that this means a newly-upgraded 16.04 member of a VM cluster<br>
might suddenly not be able to migrate any machines from itself to a<br>
14.04 member of the same cluster.  Perhaps it shouldn't be a default<br>
option.  Perhaps the target machine version should be configurable<br>
(e.g. configure libvirtd to automatically upgrade all machines as far<br>
as pc-i440fx-vivid, but no higher--persist this configuration after do-<br>
release-upgrade, until the admin changes it and all machines upgrade on<br>
migration or restart).<br>
<br>
I just think it's at least a good idea to say, "Hey, this machine's<br>
off, and I can't turn it on!  It's configured for an old or unknown<br>
machine type.  Want to update its configuration?" and the user says<br>
"Yes" and it just works.  Otherwise you have to dig into the XML<br>
configuration or run some arcane configuration commands or some such;<br>
I'm still not sure how it all works.<br></blockquote><div><br></div><div>I like your examples.</div><div>For the reasons I outlined before it can never be an auto-upgrade as that could mean way more losses to people using it.</div><div>Imagine that ever causes some sort of data corruption - being a manual task allows everybody to take this step as a conscious decision.</div><div><br></div><div>But that doesn't mean we can't do anything and as I said I like your examples, so what I'd suggest is:</div><div>- we open a bug for it to track the work on it, currently I'd define the scope to this<br></div><div>  - add documentation to <a href="https://help.ubuntu.com/lts/serverguide/libvirt.html#libvirt-management">https://help.ubuntu.com/lts/serverguide/libvirt.html#libvirt-management</a> (could use some update/extension anyway I think)</div><div>  - 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</div><div>  - not sure on virt-manager changes for that yet, but we can do and discuss that step by step</div><div><br></div><div>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.</div><div><br></div></div>
</div></div>