Hide Forgot
Created attachment 529664 [details] domain file Description of problem: I have a windows VM image which I created on F-14 or F-13. It was still working with F-15 virt stack. When I try to start it on F-16, however, the following error occurs: $ LANG=C sudo virsh start windows [sudo] password for julas: error: Failed to start domain windows error: wewnętrzny błąd zakończono proces podczas łączenia z monitorem: Supported machines are: pc Standard PC (alias of pc-0.14) pc-0.14 Standard PC (default) pc-0.13 Standard PC pc-0.12 Standard PC pc-0.11 Standard PC, qemu 0.11 pc-0.10 Standard PC, qemu 0.10 isapc ISA-only PC Version-Release number of selected component (if applicable): libvirt-0.9.6-2.fc16.x86_64 qemu-kvm-0.15.1-1.fc16.x86_64 How reproducible: always Steps to Reproduce: 1. have the domain set up 2. try to start it with virsh or virt-manager Actual results: error mentioned above Expected results: domain boots
Guests created on Fedora 13 hosts had a machine type of "fedora-13" in the configuration: <type arch='x86_64' machine='fedora-13'>hvm</type> That type was supported in F14 and F15 for backwards compatibility, but is no longer supported in F16, so any guests with that machine type will need their configuration edited to user the newer, more standard "pc-0.14": <type arch='x86_64' machine='pc-0.14'>hvm</type> To edit the guest configuration, use "virsh edit", eg: virsh edit windows in your case, and change "fedora-13" to "pc-0.14".
*** Bug 753623 has been marked as a duplicate of this bug. ***
Surely it should convert it over or at least give decent error messages to inform the user about the issue rather than a useless message. Also editing it to "pc-0.14" I still get the same error, restarted libvirtd to see if it made any difference but it didn't
Okay, I see now that the problem in your case is slightly different - your guest was running at the time of the upgrade, and was automatically saved to a disk image; the disk image contains a copy of the entire config for the guest at the time it was paused, and this config is what has the "fedora-13" string in it - you sould still need to edit the config and change that to pc-0.14, but changing the static config isn't going to do anything for the config that was saved to the disk image when the guest was paused. You can modify the xml config stored with saved images with the "virsh save-image-edit" command, eg: virsh save-image-edit /var/lib/libvirt/qemu/save/myguest.save (that directory is where automatically saved images will be located). Since migration between different versions of qemu is not guaranteed to work, a restore of a saved image to a different version of qemu is also not guaranteed to work, but you can at least give it a try. As far as whether or not it should support auto-conversion, or have a better error message, that's a valid point. I'll make sure to bring it up in discussions with other libvirt developers.
> Since migration between different versions of qemu is not guaranteed to work, a > restore of a saved image to a different version of qemu is also not guaranteed > to work, but you can at least give it a try. I tried the following: virsh edit minimal (update from fedora-13 to pc-0.14) Shitf+ZZ to save then: virsh save-image-edit /var/lib/libvirt/qemu/save/minimal.save (update from fedora-13 to pc-0.14) Shitf+ZZ to save I get the following error: error: Failed to update /var/lib/libvirt/qemu/save/minimal.save error: unsupported configuration: Target domain OS type pc-0.14 does not match source fedora-13 Is there something else that needs to be updated or a particular order? > As far as whether or not it should support auto-conversion, or have a better > error message, that's a valid point. I'll make sure to bring it up in > discussions with other libvirt developers. There needs to be something, loss of a VM from one version of KVM/qemu/libvirt isn't really ideal. Not a major problem for me currently as they're not production VMs and I can easily recover but if it was RHEV/RHEL running prod VMs I wouldn't be overly pleased.
After some discussions about the history of the "fedora-13" machine type, we've agreed that the proper course of action is for the qemu package in Fedora to re-enable the "fedora-13" machine type (which was added in during F13 when new features were backported to the F13 version of qemu). This machine type should continue to be supported in Fedora builds of qemu until a migration plan is put in place for those who have guests they created on F13 (meaning that they have this machine type).
*** Bug 753783 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > After some discussions about the history of the "fedora-13" machine type, we've > agreed that the proper course of action is for the qemu package in Fedora to > re-enable the "fedora-13" machine type (which was added in during F13 when new > features were backported to the F13 version of qemu). > > This machine type should continue to be supported in Fedora builds of qemu > until a migration plan is put in place for those who have guests they created > on F13 (meaning that they have this machine type). I disagree, we're passed the F13 end of life and there is a simple work around - need to erase the memory dump using virsh managedsave-remove command and afterwards edit the xml like mentioned above.
> I disagree, we're passed the F13 end of life and there is a simple work around Fedora 13 end of life is irrelevant. This was supported in Fedora 15 and can be trivially made to work in Fedora 16 too. If this compatibility is to be killed, it can be done in Fedora 17, provided it is clearly release-noted, and the upgrade path is documented in the release notes.
> I disagree, we're passed the F13 end of life and there is a simple work around Completely irrelevant. The VMs were created in the time frame of F-13 but are running everything from F-14 through to rawhide. There should be a check and warning that a configuration is about to go away. If it was deprecated in F-14 and later there was plenty of time for some form of warning, and even a prompt to say "this has changed and will soon be obsolete, would you like the configuration updated". Things shouldn't just break between upgrades
qemu-0.15.1-3.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/qemu-0.15.1-3.fc16
qemu-0.15.1-3.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
This update has been pushed, and will temporarily resolve the issue while we wait for t libvirt to do a more transparent fix. The patch which worked around the issue in qemu will be dropped for Fedora 17.
(I can confirm that it does solve the problem). Bug 754772 is tracking libvirt changes to automatically convert occurrences of "fedora-13" to "pc-0.13". This will go into F16 updates soon, so hopefully all occurrences of fedora-13 will be eradicated by the time F17 is released. Just in case, the libvirt patch will remain in F17 and possibly F18; when it is removed, there will be a release note to go along with it. Hopefully this strategy will get everyone converted over without need for manual intervention.