Bug 753783 - Supported machines are: pc Standard PC (alias of pc-0.14)
Summary: Supported machines are: pc Standard PC (alias of pc-0.14)
Keywords:
Status: CLOSED DUPLICATE of bug 748218
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Fedora Virtualization Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-14 13:53 UTC by Kamil Páral
Modified: 2011-11-15 21:54 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-11-15 21:54:13 UTC
Type: ---


Attachments (Terms of Use)
broken VM definition file (2.15 KB, text/plain)
2011-11-14 13:54 UTC, Kamil Páral
no flags Details

Description Kamil Páral 2011-11-14 13:53:57 UTC
Description of problem:
After upgrade from F15 to F16 some of my virtual machines can no longer be started. I receive this error:

Error starting domain: internal error Process exited while reading console log output: 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


Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 44, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1050, in startup
    self._backend.create()
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 510, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error Process exited while reading console log output: 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


Other machines can be started.


Version-Release number of selected component (if applicable):
libvirt-client-0.9.6-2.fc16.x86_64
libvirt-0.9.6-2.fc16.x86_64
libvirt-python-0.9.6-2.fc16.x86_64
virt-manager-common-0.9.0-7.fc16.noarch
virt-manager-0.9.0-7.fc16.noarch

Comment 1 Kamil Páral 2011-11-14 13:54:27 UTC
Created attachment 533529 [details]
broken VM definition file

Comment 2 Kamil Páral 2011-11-14 13:54:54 UTC
gpxe-roms-qemu-1.0.1-4.fc16.noarch
qemu-common-0.15.1-2.fc16.x86_64
qemu-system-x86-0.15.1-2.fc16.x86_64
qemu-kvm-0.15.1-2.fc16.x86_64
qemu-img-0.15.1-2.fc16.x86_64

Comment 3 Kamil Páral 2011-11-14 14:44:12 UTC
This bug may be same as bug 750881.

Comment 4 Laine Stump 2011-11-15 21:54:13 UTC
(In reply to comment #3)
> This bug may be same as bug 750881.

It's similar to that, in that qemu spits out the same message due to a machine type that's unknown by qemu, but in the case of that bug it's because ovirt incorrectly assumes that the nodes will be running RHEL but your node is running Fedora (which doesn't understand the rhelx.x.x machine types).

In your case, your guest was almost surely created when your host was running Fedora 13 and thus got the machine type 'fedora-13'. qemu retained this machine type through F14 and F15, but forgot to put it into F16, which is what's causing the problems now. 

Since 748218 was the first report filed for this problem, that's the one that will be consolidating all the reports and tracking the fix (to add fedora-13 back into the list of qemu machine types).

*** This bug has been marked as a duplicate of bug 748218 ***


Note You need to log in before you can comment on or make changes to this bug.