Bug 434580 - virt-manager cannot start guest machines anymore
virt-manager cannot start guest machines anymore
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: virt-manager (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Berrange
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-22 16:42 EST by Michel Alexandre Salim
Modified: 2008-02-28 00:02 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-28 00:02:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Windows XP guest configuration (1.14 KB, text/xml)
2008-02-22 16:42 EST, Michel Alexandre Salim
no flags Details

  None (edit)
Description Michel Alexandre Salim 2008-02-22 16:42:28 EST
Description of problem:
virt-manager worked fine for me until a couple of days ago. After today's
update, it won't start the guest machines -- it does not even get to BIOS screen.

Version-Release number of selected component (if applicable):
0.5.3-2.fc9.x86_64

How reproducible:


Steps to Reproduce:
1. virt-manager
2. Attempt to run a guest machine 
  
Actual results:
With selinux non-enforcing:
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 472, in run_domain
    vm.startup()
  File "/usr/share/virt-manager/virtManager/domain.py", line 379, in startup
    self.vm.create()
  File "/usr/lib64/python2.5/site-packages/libvirt.py", line 240, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: virDomainCreate() failed QEMU quit during console startup
bind() failed


Expected results:
Should work

Additional info:
Comment 1 Michel Alexandre Salim 2008-02-22 16:42:28 EST
Created attachment 295680 [details]
Windows XP guest configuration
Comment 2 Michel Alexandre Salim 2008-02-22 16:48:55 EST
My mistake -- the VM in question was set up before I turned on Vino, and for
some reason it ended up with a hardcoded VNC port of 5900, which is now in use

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