[libvirt] libvirt / virt-manager issue with NFS share as storage plus a philosophy question - resend w/subject

I had originally posted a plea for help on the virt-manager related list, but the same issue exists with virsh and this list seems to have higher traffic. I'd been chatting on the irc channel with various people about this, but wanted to put this on the mail list for the record and to also raise a philosophical question. First, we've confirmed that Fedora 11 preview (fully updated) has an issue with properly mounting NFS shares without the noacl option. Fedora 10 works fine with regard to mounting NFS shares. That issue causes problems when attempting to write files to an NFS share and more importantly, for this group, causes problems when attempting to create an NFS based storage pool and then subsequently creating volumes on said NFS share. That bug is 499178. This was all figured out with Openfiler support and with the support of the fine folks working on libvirt and virt-manager. There is a somewhat ugly workaround for this and I can describe it in case anyone is interested. Now comes the philosophy piece: It seems like that the way that libvirt and virt-manager want to handle storage is to be able to fully control the mounting process. That seems to me to be a very nice thing as you have a single way to manage storage along with your VMs. However, at least with respect to NFS, there are a number of parameters that people might need to give to the mount command for things like performance optimization and who knows what else. Note that this is a consideration completely aside from the bug issue above. It seems to me that either you have to just use the user created mount points, either manually or by fstab OR you have to allow all the possible options to be passed if you want to fully control the process. Right now, it's tricky to do, if you want to get paras passed for tuning or whatever and requires some tricky handwork to get it done. One way to accomplish this from the user input perspective would be to add an 'options' input field that could take multiple parameters on the step 2 of 2 page of the 'add storage pool' function. So, is my thinking all screwed up about this or is there merit to this concept? I tend to think, at least right now, that the logical thing is to either have the user create the mount points through the normal mechanisms that have in place roughly forever and then you just ask for what these are with respect to the NFS pools or you have to allow for user to pass the required parameters via your mechanism, although there are certainly many, many options when it comes to NFS. Thanks for all the help to date! I hope the above is helpful! Regards, Mike Hinz President YR20 1718 Fry Road, Suite 440 Houston, TX 77084 mike.hinz@yr20.com 832-225-1293 (o) 713-594-3095 (m) 832-550-2657 (f) Regards, Mike Hinz President YR20 1718 Fry Road, Suite 440 Houston, TX 77084 mike.hinz@yr20.com 832-225-1293 (o) 713-594-3095 (m) 832-550-2657 (f)

On Tue, May 05, 2009 at 02:40:54PM -0500, mike.hinz@yr20.com wrote:
Now comes the philosophy piece: It seems like that the way that libvirt and virt-manager want to handle storage is to be able to fully control the mounting process. That seems to me to be a very nice thing as you have a single way to manage storage along with your VMs. However, at least with respect to NFS, there are a number of parameters that people might need to give to the mount command for things like performance optimization and who knows what else. Note that this is a consideration completely aside from the bug issue above. It seems to me that either you have to just use the user created mount points, either manually or by fstab OR you have to allow all the possible options to be passed if you want to fully control the process. Right now, it's tricky to do, if you want to get paras passed for tuning or whatever and requires some tricky handwork to get it done.
One of the design goals when we added the storage APIs, was that it should not require any direct admin modification of config files to setup individual storage pool. So the XML format is intended to contain enough information to cope with the 95% of common cases. The other general libvirt design goal is that the same XML formats should be applicable to any OS/backend on which the APIs are to be implemented, so avoiding Linux-isms is desirable. Thus we'd prefer not to add capability to pass arbitrary linux mount command line options in via the XML. We could identify some set of options that are important and define a formal portable representation for them in the XML, and map that to the OS-specific mount flags internally NB, if you have user created mount points, then you can already use them, just defining a plain directory storage pool - this will just accessing files in the pre-existing directory and not try todo any of the mount/unmount steps. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
participants (2)
-
Daniel P. Berrange
-
mike.hinz@yr20.com