[clug] NFSv4 "Invalid argument"

Tue Oct 14 06:14:08 MDT 2014

On 14/10/14 22:33, George at Clug wrote:
> Hi Scott,
> 
> # mount -t nfs  -v 
> 192.168.0.12:/mnt/vg2/vol1/san12_nfs_ds1/kvm-images/images 
> /var/lib/libvirt/images mount.nfs: timeout set for Tue Oct 14 
> 21:41:41 2014 mount.nfs: trying text-based options 
> 'vers=4,addr=192.168.0.12,clientaddr=192.168.0.137'

Thank you

> 
> # chown libvirt-qemu:libvirt-qemu /var/lib/libvirt/images/mc54.img 
> chown: changing ownership of `/var/lib/libvirt/images/mc54.img': 
> Invalid argument
> 
> "You haven't answered the question of why the shares need to be owned
> by root. I'm still uncertain this is not an x/y problem." - well I
> thought I had when I reference the statement "This ownership issue
> was affecting the creation of VM images on the NFS share" ?

Apologies, I missed that - not that I understand it (yet).

> 
> I want the NFS share to be the permissions of the person/service or 
> group of the person/service who creates or modifies the file. Is this
> possible with NFS ?  I am confident that NFS can do this, at least
> with NFSv4.  The problem that exists is that I want to mount an NFS
> share to "/var/lib/libvirt/images" so that I can have virt-manager
> from any hypervisor-server that is on my network, access the NFS
> share and run my virtual machines that are in the NFS share. However
> when I attempt to do this the owner of the images is nobody:nogroup
> with permissions of 600, and virt-manager cannot access the virtual
> machine image files.

There are a couple of ways that 'might' be dealt with (either change the
groups that virt-manager belongs to, change the ownership of the nfs
share by remount/bind or /etc/exports). I'll have to have a think about
it overnight and maybe do a little research as to the safest way.

> 
> "Error starting domain: internal error Process exited while reading 
> console log output: char device redirected to /dev/pts/2 kvm: -drive
>  
> file=/var/lib/libvirt/images/MC43.img,if=none,id=drive-virtio-disk0,format=raw:
>
>
>  could not open disk image /var/lib/libvirt/images/MC43.img:
> Permission denied"

Thanks

> 
> It seems that I am unable change the ownership of the files, but 
> since you asked me why I wanted to do this, I have now tried to 
> change the permissions of the files, and this worked, and 
> virt-manager can run the virtual machine images. Though now security 
> is some what degraded. chmod 666 /var/lib/libvirt/images/MC43.img
> 
> "Please just click on the "Reply" button in your MUA instead of 
> creating a new post" - it seems I am doing something wrong, just not 
> sure what.  If I click on my reply button, I only get the email of 
> the person who responded, not  linux at lists.samba.org, so I click 
> reply all, though I don't think this is causing the issue you are 
> referring to.

> Would you be referring to me removing the "Re:" part of the email?  I
> can stop that but then the email will not start with [clug] which I
> thought it was supposed to ?

Changing the subject line 'shouldn't' break the thread - but I'm not
familiar with your MUA, so maybe it does in this case (anyone else??).
See attached (tiny) screenscrape showing threading.

> Apologies, I am still not sure of the email forum conventions, I am
> more used to phpbb3 style of forums. I can learn, so please let me
> know.

I'm not familiar with your MUA. Some have a "Reply to list" option -
others just have a "Reply" option that uses the last sender address - in
this instance it would use my address instead of the list address. You
could (possibly) just change the address.

I use a screen-reader so what bothers me might not bother others.

> 
> Thank you for your responses and comments.  Sometimes I try things 
> that just don't make sense in a linux world because I do not fully 
> understand how the system works.

Does anyone? :)
I really do appreciate those that adapt - though I've long since
forgotten how hard it was to learn to ride the bike (training wheels!
really?). It was difficult.

> For example, while I wanted to map "/var/lib/libvirt/images" to an 
> NFS share, this is evidently not how virt-manager works with virtual 
> machine images, it needs more than just the virtual machine's *.img 
> file, and the xml file that it also uses is not located in 
> "/var/lib/libvirt/images", so it is not as easy as just sharing the 
> directory that the *.img file resides in. In fact I don't think that 
> virt-manager is designed to work this way (sadly), but I will learn 
> more about virt-manager as I get to spend more time working with it. 
> At this point I can say, I am impressed how well Debian Wheezy 
> running KVM and virt-manager runs in VMware Workstation (on Windows 
> 7) which I am currently using for this testing. I have about 3TB of 
> NFS share in an OpenFiler virtual machine also running in VMware 
> Workstation as this is where I had previously been testing ESXi VM 
> migration, HA, etc, so since I had the NFS share, it was quick for
> me to use it in transferring VMs from a physical
> Debian-KVM-Virt-Manager server to my VMware Workstation hosted
> Debian-KVM-Virt-Manager server (e.g. my test environment).

Both have a solid industry reputation - Debian and VMware. Unfortunately
I'm not the person to ask about VMware (more xen, chroot and VirtualBox).

> 
> If anyone is familiar with virt-manager, I am interested if and how 
> it is designed to work with NFS Shared storage for virtual machines. 
> It seems that virt-manager supports "dir:", "disk:", "iscsi:", 
> "logical:", "mpath:", "netfs:", and "scsi:" ??
> 
> http://osdir.com/ml/libvir-list/2009-05/msg00080.html  - please read
>  this, maybe it has something to do with my issues ?

Closed: 	2009-06-03 03:44:38 EDT see:-
https://bugzilla.redhat.com/show_bug.cgi?id=499178#c4

Unlikely to be the problem you are experiencing

------------8<------------->8-----------------------
> 
> 
> 
> is the shares do not need to be owned by "root" as far as I know,
> but I answered the best I could, by referring to; "Before I specified
> a domain on my servers, files created on the NFS shares had
> ownership nobody.nobody, regardless of what user created it (even
> root). This ownership issue was affecting the creation of VM images
> on the NFS share, which was fixed after I specified a domain in 
> /etc/idmapd.conf. My VM images now have ownership qemu.qemu, as it 
> should be."

Excellent!

> 
------------8<------------->8-----------------------

Kind regards