qemu machine types broken in wily and missed to be updated in xenial and yakkety
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
qemu (Ubuntu) |
Fix Released
|
Critical
|
Unassigned | ||
Xenial |
Fix Released
|
High
|
Unassigned |
Bug Description
[Impact]
* Without proper default types migration to further releases can hardly be maintained for Ubuntu
* Avoiding several weird cases that were caused by the double default and double alias to different machine types
[Test Case]
* spawn a kvm guest and check its (default) type - should be Ubuntu specific
* migrate that guest to a subsequent Ubuntu release
* Detailed tests are available at https:/
[Regression Potential]
* There could be combinations of qemu releases that won't be able to migrate between each other. We tested the supported forward to next release migration. But we also tested the migration between systems with and without the SRU in case customers apply the change at different times.
* Testing was done as outlined in the bug in detail. There are issues left regarding migration, but we fixed several old ones and didn't open up a new one with that SRU contribution. See the logs in the bug for details. Comment #7 has a summary.
[Other Info]
* There is a lot of general background info on the topic available at https:/
---
The machine type definition in Wily still refers to compat 2.3 despite being a 2.4 qemu.
Also there was no update at all for Xenial and Yakkety, which is why they start by default with this broken type pc-i440fx-wily.
Ubuntu delta to machine types has to be updated in devel release and SRUed into Xenial at least.
Impact: lack of machine features and broken migration from the failing releases.
Changed in qemu (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → High |
importance: | High → Critical |
Changed in qemu (Ubuntu Xenial): | |
status: | New → Triaged |
importance: | Undecided → High |
tags: | added: patch |
description: | updated |
description: | updated |
To $(clarify or argue :),
A xenial machine type should indeed be defined based on the newest
mt available in xenial, and SRU'd to xenial. A yakkety type should
probably be defined at the end of the y cycle, and obviously not
SRUd.
Thanks.