Bug 227169 - Fully virtualized virt-install fails from a read-write NFS share (release note)
Fully virtualized virt-install fails from a read-write NFS share (release note)
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: redhat-release-notes (Show other bugs)
5.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Don Domingo
Michael Hideo
https://bugzilla.redhat.com/bugzilla/...
: Documentation
Depends On:
Blocks: 197865
  Show dependency treegraph
 
Reported: 2007-02-02 16:38 EST by Archana K. Raghavan
Modified: 2010-03-14 17:31 EDT (History)
0 users

See Also:
Fixed In Version: 5.0.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-01 13:09:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Archana K. Raghavan 2007-02-02 16:38:05 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.5) Gecko/20060726 Red Hat/1.5.0.5-0.el4.1 Firefox/1.5.0.5 pango-text

Description of problem:
1)  Mount remote server to serve out the boot.iso (e.g. mount
server:/path/to/RHEL/ /mnt/tmp
2)  virt-install -n rhel4fvtest -r 1024 -f /var/lib/xen/images/rhel4fvtest.dsk
-s 6 --nonsparse -c /mnt/tmp/images/boot.iso -v --vnc
3)  It will say "Starting install...", and after some time (because of the
--nonsparse), it will spew a traceback like the following:

libvir: Xen Daemon error : POST operation failed: (xend.err 'destroyDevice()
takes exactly 3 arguments (2 given)')
Failed to get devices for domain rhel4fvtest
Traceback (most recent call last):
  File "/usr/sbin/virt-install", line 447, in ?
    main()
  File "/usr/sbin/virt-install", line 411, in main
    dom = guest.start_install(conscb)
  File "/usr/lib/python2.4/site-packages/virtinst/XenGuest.py", line 367, in
start_install
    self.domain = self.conn.createLinux(cxml, 0)
  File "/usr/lib64/python2.4/site-packages/libvirt.py", line 249, in createLinux
   if ret is None:raise libvirtError('virDomainCreateLinux() failed')
libvirt.libvirtError: virDomainCreateLinux() failed

The interesting thing here is that although virt-install failed, it still
*created* the fully virt domain.  However, it never unpaused the domain. 
Interestingly, you can actually go ahead and unpause the domain (xm unpause
<dom>), but because virt-install failed it will never write out a valid
configuration.  I'm not sure what the solution is (since I understand that we
don't necessarily want to run around destroying domains), but this behavior is
confusing to end users.

mounting the NFS share read-only allows the install to start
successfully.  It's only when mounting the very same NFS share read-write that I
run into the failure.

This needs to be documented in the release notes.  Don, you are probably better at wording this. Also, make sure to add:
if it is not possible to mount the NFS share read-only for some reason, the workaround is to copy the boot.iso locally into /var/lib/xen/images"



Version-Release number of selected component (if applicable):


How reproducible:
Always


Steps to Reproduce:
1)  Mount remote server to serve out the boot.iso (e.g. mount
server:/path/to/RHEL/ /mnt/tmp
2)  virt-install -n rhel4fvtest -r 1024 -f /var/lib/xen/images/rhel4fvtest.dsk
-s 6 --nonsparse -c /mnt/tmp/images/boot.iso -v --vnc
3)  It will say "Starting install...", and after some time (because of the
--nonsparse), 

Actual Results:
it will spew a traceback like the following:

libvir: Xen Daemon error : POST operation failed: (xend.err 'destroyDevice()
takes exactly 3 arguments (2 given)')
Failed to get devices for domain rhel4fvtest
Traceback (most recent call last):
  File "/usr/sbin/virt-install", line 447, in ?
    main()
  File "/usr/sbin/virt-install", line 411, in main
    dom = guest.start_install(conscb)
  File "/usr/lib/python2.4/site-packages/virtinst/XenGuest.py", line 367, in
start_install
    self.domain = self.conn.createLinux(cxml, 0)
  File "/usr/lib64/python2.4/site-packages/libvirt.py", line 249, in createLinux
   if ret is None:raise libvirtError('virDomainCreateLinux() failed')
libvirt.libvirtError: virDomainCreateLinux() failed

Expected Results:
Worked fine

Additional info:
Comment 1 Don Domingo 2007-02-04 19:36:23 EST
Hi Archana,

please check:

<quote>
Creating a fully virtualized guest using a boot.iso on a mounted NFS share will
not complete correctly. To prevent this, copy the boot.iso to
/var/lib/xen/images/ before using it to create the guest.
</quote>

also, please verify if this only affects x86. 

thanks!
Comment 2 Don Domingo 2007-02-04 19:41:30 EST
by the way, please confirm within 24 hours of this message. i apologize for the
hurry, but i'd rather this went into the distro Release Notes, and we have a
very small window through which we can re-spin and let Translation pick this up
on their next run of the Release Notes. 
Comment 3 Archana K. Raghavan 2007-02-05 13:38:54 EST
Hi Don,

You might want to change it this way:
==================================================
Creating a fully virtualized guest using a boot.iso on a mounted NFS share will
not complete correctly unless the nfs share is mounted read only. If the nfs
share cannot be mounted read only, the boot.iso should be copied to
/var/lib/xen/images directory locally.
==================================================

Will that work? Just wanted to emphasize that mounting the nfs share as read
only works.
Comment 4 Don Domingo 2007-02-05 18:28:25 EST
is this bug specific to the i386 / x86 arch only?

edited as:

<quote>
Creating a fully virtualized guest using a boot.iso on an NFS share mounted as
read-write will not complete correctly. To work around this problem, mount the
NFS share as read-only.

If you are unable to mount the NFS share as read-only, copy the boot.iso to the
local /var/lib/xen/images/ directory. 
</quote>
Comment 5 Archana K. Raghavan 2007-02-05 18:52:16 EST
Don,

Yes xen itself is only on i386 and x86_64 arch. Not sure about ia64 (how much is
supported).

The edited text looks good. 

Thanks,
Archana
Comment 6 Don Domingo 2007-02-05 19:26:33 EST
thanks. adding this note to the ia64, x86 and x86_64 Release Notes, then.
Comment 7 Don Domingo 2007-03-13 21:23:52 EDT
this is already noted in release notes as specified. closing this item
CURRENTRELEASE.

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