Red Hat Bugzilla – Bug 245119
virt-manager times out when pre-allocating a simple file disk
Last modified: 2008-08-02 19:40:36 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20070515 Firefox/126.96.36.199
Description of problem:
while creating a new virtual machine, choosing a simple file of 8000MB and checking the "allocate entire virtual disk now" causes a time out error.
the disk creation completes, then the create domain fails with:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.create a virtual machine (i used kvm, not sure if relevant)
2.under "assigning storage space", choose simple file, size 8000MB, check "alloacte entire virtual disk".
3.continue as usual.
Unable to complete install '<class 'libvirt.libvirtError'> virDomainCreateLinux() failed internal error Timed out while reading console startup output
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/create.py", line 681, in do_install
dom = guest.start_install(False, meter = meter)
File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 649, in start_install
return self._do_install(consolecb, meter)
File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 666, in _do_install
self.domain = self.conn.createLinux(install_xml, 0)
File "/usr/lib64/python2.5/site-packages/libvirt.py", line 503, in createLinux
if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: virDomainCreateLinux() failed internal error Timed out while reading console startup output
creation of disk and virtual machine
workaround is to not pre-alloacte the disk
Can you update to libvirt-0.2.3, restart 'service libvirtd restart' and then
try again. You should get a different, more meaningful error, as well as logfile
in /var/log/libvirt telling you exactly what went wrong. That error basically
means qemu was starting up, but exited immediately, so we need to find out the
real cause of this.
the current libvirt is already libvirt-0.2.3-1.fc7...
the /var/log/libvirt/qemu/large.log file only contains the qemu command and:
"char device redirected to /dev/pts/2
Hmm, that's rather odd then.
Can you tell me if /var/log/libvirt/qemu/large.log file contains a newline
character \n immediately following the /dev/pts/2 ?
Also, can I get a copy of the /root/.virt-manager/virt-manager.log and
Finally, am I understanding your initial comment correctly, but saying that if
you do not pre-allocate the 8 GB disk, it starts up fine ?
Created attachment 157544 [details]
i cleared the various files, and reproduced everything using "large5".
(since before, it contained both unsuccessful and successful runs
i attached the large5.log.
the other 2 files do not exist at all now.
and yes, if i do not pre-allocate the disk, everything is working (i actually
got this problem from someone else, and reproduced it, so i know it is not
something local to my computer).
it does not always happen with a 4000 MB file. so maybe try with a 16000MB file...
Ok, this sounds like a high VM-load related issue. Pre-allocating a 4 GB file
will cause 4 GB worth of data to be written to disk which will fill up the
buffer cache quite significantly. When you then start a 500 MB guest, the kernel
has to flush out a fair bit of data to disk to be able to allocate memory to
QEMU/KVM. This could cause startup of QEMU to be slow enough that libvirt times
out waiting for it to start. I'll have ago at reproducing this problem.
This is a pretty old bug, is anyone still seeing this or was it ever
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present. Since there have not been any
updates to the report since thirty (30) days or more since we
requested additional information, we're assuming the problem
is either no longer present in the current Fedora release, or
that there is no longer any interest in tracking the problem.
Setting status to "CLOSED INSUFFICIENT_DATA". If you still
experience this problem after updating to our latest Fedora
release and can provide the information previously requested,
please feel free to reopen the bug report.
Thank you in advance.
Note that maintenance for Fedora 7 will end 30 days after the GA of Fedora 9.