Red Hat Bugzilla – Bug 436179
Fails to start HVM DomU
Last modified: 2008-11-26 10:41:34 EST
Description of problem:
DomU previously worked, but now fails to start with following error:
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/engine.py", line 472, in run_domain
File "/usr/share/virt-manager/virtManager/domain.py", line 379, in startup
File "/usr/lib/python2.5/site-packages/libvirt.py", line 240, in create
if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: virDomainCreate() failed POST operation failed: (xend.err 'int
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot system
2. Launch virt-manager, double-click localhost, double-click DomU
3. Click Run
Error message as displayed above
DomU should start and display running console
Created attachment 296915 [details]
Created attachment 296916 [details]
Created attachment 296917 [details]
List of packages that have changed since the last successful running of this
DomU. Appears to perhaps be related to latest xen and xen-libs update?
Can you do a 'virsh dumpxml <guestname>' and 'xm list --long <guest name>' from
the console and post the results here? Thanks.
Well, I got this to eventually work. I had never had an virsh xml file, nor an
xm config file, I had only ever used virt-manager to create/install initially
and subsequently start the WinXP HVM. I did as you seem to be sending me, the
'virsh dumpxml WinXP > WinXP.xml' , and subsequently I did a 'virsh create
WinXP.xml' and got it to start. Of course, my time was off (defaulted
apparently to utc) and my mouse gave me fits of not 'fully' following me. I am,
unfortunately, attaching the now fixed up xml file of the "running" DomU (all I
changed was the clock and mouse lines), but got it working with virsh create then.
Created attachment 297110 [details]
Created attachment 297111 [details]
xm list --long
Using guests based on config files isn't actually what I meant, I just wanted to
see the output. I'm more interested in how you got that original error.
Can you still reproduce the original error? If so, can you reproduce by creating
a new guest or just by using a pre-existing one? Also if you are still having
issues, please give the version of python-virtinst as well.
Well, not sure how I got the original error, but it has re-appeared this evening....
"Fixing" is the following steps:
xm destroy WinXP
service xend restart
virsh create WinXP.xml
Then I can connect to the console through virt-manager. It also now can be
shutdown from virt-manager and "run" again later. Still not sure what
precipitated the initial "breakage", but the fact that it recurs is interesting
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '8'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 8's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 8 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Hi, this bug has been sitting still for quite a while. If anyone can find a way
to reliably report the initial error, please file a bug against xen. I'm pretty
certain this isn't a virt-manager issue: virt-manager does all it's work
through libvirt or xen. So setting to CLOSED. If I got this wrong, please