"Dr. David Alan Gilbert" <dgilb...@redhat.com> writes: > * Daniel P. Berrange (berra...@redhat.com) wrote: >> On Wed, May 10, 2017 at 03:51:25PM +0100, Dr. David Alan Gilbert wrote: >> > * Daniel P. Berrange (berra...@redhat.com) wrote: >> > > If we deprecate in this release (~Aug/Sep 2017), and kill in the next >> > > release (Dec 2017), that means our oldest machine type pc-1.0 is still >> > > going to be 6 years, or 18 major releases, old. This raises some >> > > questions >> > > >> > > - Do we really think that we still have users with VMs that are >> > > stuck on a 6 year old machine type from 18 major releases ago ? >> > >> > Our RHEL6 users are still on a 0.12 derivative. >> >> Yep, but not using upstream machine types. So we can kill machine >> types without affecting RHEL-6. The separate question is whether >> we can kill the associated features that are needed for RHEL to >> create its legacy machine types (eg the rombar setting mentioned) > > Right, it just felt a bit odd to kill it off upstream if we know > of users ourselves who use old versions like that. > > Also remember machine types are not just about migration compatibility; > if we kill a machine type then: > a) The users will need to modify their libvirt xml for each VM to > change machine type
Point taken. But if this inconvenience is unacceptable, consider an enterprise distribution, or maybe CentOS. > b) That change in guest view of the machine might upset the OS > installed. Unlikely, unless you migrate without a reboot. Guests almost always adapt to minor hardware changes on reboot just fine. > I've certainly got VMs that were installed ages ago and are still using > the XML from the old installation; so that probably means using an old > machine type on a modern QEMU. Eventually, that becomes as likely to actually work as rebooting with a newer machine type :)
