Hide Forgot
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:
Component changed due to a bit more analysis and a SWAG.
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.
Half a year old and still no answer on this - indeed still in "new" state. I'm disappointed.
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
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?
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.
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'
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.
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.
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.
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
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.