Bug 243544

Summary: virt-install/virt-manager don't follow RFC 2224 for NFS mounts
Product: [Fedora] Fedora Reporter: Tom Wood <woodt>
Component: python-virtinstAssignee: Cole Robinson <crobinso>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: 8CC: crobinso, herrold, katzj, mwc, triage
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 0.5.3-1.fc7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-11-25 14:06:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Tom Wood 2007-06-09 16:32:09 UTC
Description of problem:  Unlike the http and ftp based installation options,
xen's guest creation tools don't follow a standard RFC-based nomenclature for
specification of an NFS install location.  The Red Hat documentation specifies
properly what the current xen tools will accept.  For example,
nfs:nfsserver.example.com:/distro/files is what the tools expect.  However, RFC
2224 specifies that the format should be
nfs://nfsserver.example.com/distro/files .  This format is based on RFC 1738
which defines the general format of all URLs.

There is one intriguing side effect of using a RFC 2224 conformant URL with the
existing tools - the tools then start mount.cifs - yes, that's right.  They
interpret the RFC 2224 compliant NFS mount location as a CIFS mount location.  I
find that especially interesting considering that Samba shares aren't an
officially supported mechanism for xen guest installation sources.  Must be a
bug in a library somewhere.  Should I file that as a separate bug?

Version-Release number of selected component (if applicable):  xen
3.1.0-0.rc7.1.fc7, probably others.


How reproducible:  Every time


Steps to Reproduce:
1.  Run either virt-manager or virt-install.
2.  Respond with an RFC 2224 compliant URL for an NFS mount when asked for
install location.
3.  Run "ps aux" quickly thereafter and be amazed as a CIFS mount is attempted.
4.  If running from virt-install, observe "Password:" prompt in whatever shell
you started virt-install.

  
Actual results:  Failure.


Expected results:  NFS mount to complete and successful installation.


Additional info:

Comment 1 Tom Wood 2007-06-09 16:37:39 UTC
Component changed due to a bit more analysis and a SWAG.

Comment 2 Michael Carney 2007-09-21 18:25:37 UTC
It's embarrassing that virt-inst gets this wrong. It should really handle a 
proper nfs URI. (e.g nfs://). Backward compatible is ok, but we shouldn't be
confusing folks who use a properly formed nfs URI and find it fails.

The severity should be higher, like perhaps medium.

Comment 3 Tom Wood 2007-12-17 01:04:39 UTC
Half a year old and still no answer on this - indeed still in "new" state.  I'm
disappointed.

Comment 4 Daniel Berrangé 2007-12-17 01:42:58 UTC
The reason it expected 'nfs:' is because the URL is passed straight through to
Anaconda as the install source. Since anaconda wanted non-RFC URIs, virt-install
was made to match.

We have since added support for installing other distros, and recently made
virt-install support both  nfs: and nfs:// and will auto-translate into the
format required by anaconda.

It'll be in the next release that is done

http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=be8457357ab2

Comment 5 Tom Wood 2007-12-17 02:07:58 UTC
That was a quick response!  Thanks for the info.  I'm still curious why only the
NFS mount case has/had a non-RFC-compliant URI, whereas the http and ftp cases
are/were already compliant.

The second part of my bug report, namely mount.cifs being called when I tried a
RFC-compliant URI for an NFS mount, still concerns me.  Is this merely a
side-effect of the mishandling of the RFC-compliant form of the NFS case, or
something else?

Comment 6 Tom Wood 2007-12-17 02:20:42 UTC
That was a quick response!  Thanks for the info.  I'm still curious why only the
NFS mount case has/had a non-RFC-compliant URI, whereas the http and ftp cases
are/were already compliant.

The second part of my bug report, namely mount.cifs being called when I tried a
RFC-compliant URI for an NFS mount, still concerns me.  Is this merely a
side-effect of the mishandling of the RFC-compliant form of the NFS case, or
something else?

Comment 7 Cole Robinson 2007-12-17 19:46:37 UTC
The reason you were seeing mount.cifs seems to be a side effect of how we were
parsing nfs locations. In order to install from an nfs source tree, we would
mount the tree and grab a boot kernel. Since nfs uris were expected as
nfs:server:/path/to/tree, we would chop off the 'nfs:' and pass the rest to the
'mount' command. In the case of 'nfs://' this left '//server:/path/to/server'
which if you try with 'mount' defaults to using mount.cifs and gives a password
prompt.

Comment 8 Fedora Update System 2008-01-11 22:26:39 UTC
virt-manager-0.5.3-1.fc7, gtk-vnc-0.3.2-1.fc7, python-virtinst-0.300.2-1.fc7, virt-viewer-0.0.2-1.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update virt-manager gtk-vnc python-virtinst virt-viewer'

Comment 9 Fedora Update System 2008-01-22 15:37:51 UTC
virt-manager-0.5.3-1.fc7, gtk-vnc-0.3.2-1.fc7, python-virtinst-0.300.2-1.fc7, virt-viewer-0.0.2-1.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 10 Cole Robinson 2008-01-22 15:43:38 UTC
hmm, this still isn't RFC complete. now we can parse nfs:server:/path/to/tree
and nfs://server:path/to/tree, but NOT nfs://server/path/to/tree which is needed
for RFC compliance. Reopening this bug.

Comment 11 Cole Robinson 2008-02-05 17:05:16 UTC
Full fix now upstream: 

http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=aa3fe23be510

Putting bug in POST until we cut a new release and pull it into fedora.

Comment 12 Bug Zapper 2008-05-14 12:58:21 UTC
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. 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 '7'.

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 7'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 7 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. 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. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 13 Cole Robinson 2008-11-25 14:06:16 UTC
Since it is pretty late for F8, I'd rather not update the package for this non-critical feature that is in a known fragile code path (url munging and kernel fetching).

This is fixed in F9 though, so closing as CURRENTRELEASE.