Bug 390291 - cannot create XEN virtual machines
cannot create XEN virtual machines
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xen (Show other bugs)
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Xen Maintainance List
Virtualization Bugs
Depends On:
  Show dependency treegraph
Reported: 2007-11-19 08:15 EST by Thorsten Stärk
Modified: 2009-12-14 16:25 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-20 08:45:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Thorsten Stärk 2007-11-19 08:15:16 EST
Description of problem:

When I start virt-manager and chose File|New machine and chose an nfs
installation source, the installation lasts forever.

How reproducible:

Steps to Reproduce:
1. start virt-manager
2. chose File|New machine -> -> System1 -> paravirtualized -> enter an NFS
installation source -> Simple File -> Shared physical device -> -> Finish
Actual results:
Installation lasts forever

Expected results:
Installation does not last forever

Additional info:
Every second, I get on the console:
libvir: error : library call virConnectNumOfDefinedNetworks failed, possibly not
libvir: error : library call virConnectNumOfNetworks failed, possibly not supported
Comment 1 Daniel Veillard 2007-11-19 10:04:39 EST
I think the message every second and the installation time may be unrelated.
I did install over an NFS mounted partition in the past, it was slower
than local disk install due to network access but worked, I would probably
need to retry. For the message could you make sure you have the 
libvirt daemon running, it is started by '/etc/init.d/libvirtd start'
and should have spun off a dnsmasq instance too ?
Also for NFS install, please make sure you checked the box asking for
initialization of the disk space, it does a zeroing allocation of the
file used for the volume before starting the new domain, which may look
a bit long initially, but avoid really costly reallocation routines while
the filesystem grows during installation. It precisely avoided such case
of very long installation times we hit if the volume wasn't initialized ahead
of time.
If that's not the problem, could you specify at what point the installation
starts to stall ?

Comment 2 Thorsten Stärk 2007-11-19 10:45:31 EST
Thanks to your hints, the error message every second no longer appears. Thanks.
Now I see I am asked for a password in the console. As soon as I enter whatever
as password, the installation stops with the console error message:

[root@ls3099 ~]# virt-manager
mount error 5 = Input/output error
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
umount: /var/lib/xen/virtinstmnt.ypwgWQ: not mounted

and I get the graphical error msg:

Unable to complete install 'exceptions.RuntimeError Invalid install location
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.4/site-packages/virtinst/Guest.py", line 647, in
    tmpfiles = self._prepare_install_location(meter)
  File "/usr/lib/python2.4/site-packages/virtinst/ParaVirtGuest.py", line 65, in
    (kernelfn,initrdfn,args) = DistroManager.acquireKernel(self.location, meter,
scratchdir=self.scratchdir, type=self.type)
  File "/usr/lib/python2.4/site-packages/virtinst/DistroManager.py", line 566,
in acquireKernel
    raise RuntimeError, "Invalid install location"
RuntimeError: Invalid install location
Comment 3 Thorsten Stärk 2007-11-19 10:50:08 EST
I am now using a normal file, no nfs location, and no network. Now it works.
Comment 4 Thorsten Stärk 2007-11-19 10:58:18 EST
I have now performed the installation procedure exactly as the first time, but
only replaced the
nfs://vol/what/ever/path/x86_64/RHEL5.1-Server-20071017.0-x86_64-DVD.iso by 
and it works.
Comment 5 Daniel Veillard 2007-11-20 08:45:27 EST
Ahhh, okay, I misunderstood the problem.
Virt-manager (and in general all the stack) will manipulate NFS files
transparently using their file paths as they are seen when mounted.
Trying to mount filesystem on the fly raises the problem of the
authentication and associated user interface, it's better to have them
pre-mounted (or automatically available via automount).
I assume the problem is solved at this point, if it's not the
case please reopen explaining what is still blocking you,


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