Cannot create NFS SR from QNAP

nilsan commented 5 years ago

Trying to create a new SR (VDI SR or ISO SR) from QNAP NAS NFS in Xen Orchestra fails.

I insert server IP address (withouth share path) in the Server field and click the spyglass icon. I then get a red popup error message "unknown error from the peer" with the following log message: "Cannot read property 'nfs-exports' of null".

This happens regardless of using NFSv3 or NFSv4.

However, I can both list exports (showmount) from the QNAP and mount shares if I do it manually in Linux on the XCP-ng host.

List of versions in use

xoa: 5.30.0
xo-server: 5.32.2
xo-web: 5.32.1
xcp-ng: 7.6.0
QNAP TS-873U-RP: 4.3.5.0760

Extended log message from Xen Orchestra

sr.probeNfs
{
  "host": "281bbf63-56c4-405e-b3fb-b48f8fc492b7",
  "server": "172.18.9.34"
}
{
  "message": "Cannot read property 'nfs-exports' of null",
  "stack": "TypeError: Cannot read property 'nfs-exports' of null
    at Xo.<anonymous> (/usr/local/lib/node_modules/xo-server/src/api/sr.js:389:26)
    at throw (native)
    at asyncGeneratorStep (/usr/local/lib/node_modules/xo-server/dist/api/sr.js:40:103)
    at _throw (/usr/local/lib/node_modules/xo-server/dist/api/sr.js:42:291)
    at run (/usr/local/lib/node_modules/xo-server-xoa/node_modules/core-js/modules/es6.promise.js:75:22)
    at /usr/local/lib/node_modules/xo-server-xoa/node_modules/core-js/modules/es6.promise.js:92:30
    at flush (/usr/local/lib/node_modules/xo-server-xoa/node_modules/core-js/modules/_microtask.js:18:9)
    at _combinedTickCallback (internal/process/next_tick.js:73:7)
    at process._tickCallback (internal/process/next_tick.js:104:9)"
}

xe sr-probe

[root@vm02 ~]# xe sr-probe type=nfs device-config:server=172.18.9.34
Error code: SR_BACKEND_FAILURE_101
Error parameters: , The request is missing the serverpath parameter,

showmount

[root@vm02 ~]# showmount -e 172.18.9.34
Export list for 172.18.9.34:
/vm      
/Public  
/Web

rpcinfo

[root@vm02 ~]# rpcinfo -t 172.18.9.34 nfs
program 100003 version 2 ready and waiting
program 100003 version 3 ready and waiting
program 100003 version 4 ready and waiting

manual mount

[root@vm02 ~]# mount -v -t nfs 172.18.9.34:/vm /mnt
mount.nfs: timeout set for Thu Dec 13 12:08:33 2018
mount.nfs: trying text-based options 'vers=4,addr=172.18.9.34,clientaddr=10.187.2.8'

[root@vm02 ~]# df -h /mnt/
Filesystem       Size  Used Avail Use% Mounted on
172.18.9.34:/vm  5.5T   17G  5.5T   1% /mnt

[root@vm02 ~]# mount |grep mnt
172.18.9.34:/vm on /mnt type nfs4 (rw,relatime,vers=4.0,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=10.187.2.8,local_lock=none,addr=172.18.9.34)

olivierlambert commented 5 years ago

Note: we can reproduce in NFS v4 only, this fails with xe CLI too, and XCP-ng Center. It seems the issue is the same on XenServer.

Cory-Watson commented 5 years ago

Having the same issue on XCP-ng Center 7.6.1 and 7.6.3.

Can mount NFS locally on the XCP-ng hosts, but XCP-ng Center always errors out: "Creating SR SM has thrown a generic python exception Check your settings and try again."

olivierlambert commented 5 years ago

Do you have the same issue with XO and/or xe CLI?

jbeangreen commented 5 years ago

Error war erroneous. A simple change on the NFS for non root mount allowed and and a chmod 777 allowed xcp-ng to mount the ISO store.

eelcovb commented 4 years ago

Same issue here with XCP-NG 8.1 beta and NFS on QNAP QTS 4.4.1.

nilsan commented 4 years ago

I have some good news regarding this issue. I managed to create both VDI SR and ISO SR via NFS on QNAP units (cli only).

The main problem is that xe sr-probe returns an empty list, which means I get the log message "Cannot read property 'nfs-exports' of null" while trying to create SR in XOA.

sr-probe problem

[virt01] # xe sr-probe type=nfs device-config:server=172.18.250.33 device-config:serverpath=/ device-config:nfsversion=4
\<?xml version="1.0" ?>
\<SRlist/>

full XOA log

sr.probeNfs
{
  "host": "5c753d56-f10d-428a-bffe-9c5f2b80fc27",
  "server": "10.0.0.33"
}
{
  "message": "Cannot read property 'nfs-exports' of null",
  "name": "TypeError",
  "stack": "TypeError: Cannot read property 'nfs-exports' of null
    at Object.probeNfs (/usr/local/lib/node_modules/xo-server/src/api/sr.js:472:26)
    at <anonymous>"
}

manual mount works

[virt01] # showmount -e 10.0.0.33
Export list for 10.0.0.33:
/vm      
/iso

[virt01] # mount -t nfs 10.0.0.33:/iso /mnt/

[virt01] # df -h /mnt/
Filesystem          Size  Used Avail Use% Mounted on
10.0.0.33:/iso   65T   17G   65T   1% /mnt

Create ISO SR

[virt01] # xe sr-create name=iso type=iso content-type=iso device-config:location=10.0.0.33:/iso name-label=iso device-config:nfsversion=4
>9256c30a-94ed-676c-26ec-7c822d10512f

Create VDI SR

[virt01] # xe sr-create type=nfs device-config:server=10.0.0.33 device-config:serverpath=/vm name-label=vm-storage device-config:nfsversion=4
2936a5fb-0afa-77ad-cc84-c0fb9c29d617

Observations

NFS share has to be read/write (no read-only ISO SR)
NFSv4 works, but has to be specified in via xe device-config:nfsversion=4
I have an old pool which was upgraded from XenServer 6 to XCP-ng 7.6 where existing NFS SR work, but we can not create new ones. I have had this problem with all XCP-ng versions from 7.4 to 8.0.0.

olivierlambert commented 3 years ago

Some news, I have a theory on this issue: https://github.com/xapi-project/sm/issues/511

ventra007 commented 3 years ago

Hi,

I stumbled onto this thread, but I was looking for something related to Synology as I'm experiencing the same isssue.

I eventually did it via the cli, but as I'm running a pool with multiple hosts I had to modify the above command:

xe sr-create type=nfs device-config:server=(your server ip) device-config:serverpath=/yourpath name-label=(whatever) shared=true host-uuid=(the master host)

Hope this helps someone else, and perhaps devs can fix the way XO requests this from the web interface to how the cli does it?

Thanks

olivierlambert commented 3 years ago

Please check if there's an issue like this already opened or open a new one on XO bug tracker, linking it to here :+1:

olivierlambert commented 3 years ago

Hi @ventra007 @nilsan @eelcovb @Cory-Watson @jbeangreen

Good news: we are about to get our fix merged in upstream! See https://github.com/xapi-project/sm/pull/548

It was exactly what I suspected in https://github.com/xapi-project/sm/issues/511

I don't know why some QNAP devices aren't returning ACLs, but now we handle the case anyway. When it's merged, we'll merge the fix in XCP-ng at some point (eg when we have other updates so it will go with an "update train").

Before that, it would be wonderful if you accept to test again with a package in our testing repo. If you are interested, we'll put that in testing so you can confirm the fix!

benjamreis commented 3 years ago

Hello a fix is available on our testing repo, you can run yum update sm sm-rawhba --enablerepo=xcp-ng-testing on an host, reboot and try again to create the NFS SR.

Please report if it solves your issue or not.

Regards

stormi commented 3 years ago

Hi everyone. Benjamin has made a fix for you 1 month ago, and it would really help to get feedback on it. Without this we won't make it an official update.

benjamreis commented 3 years ago

Hello!

Has anyone been able to test this update? We really need the community feedback to make a real release of the update.

Thanks

olivierlambert commented 3 years ago

Our fix has been merged upstream: https://github.com/xapi-project/sm/pull/548 :partying_face:

@stormi should we close it here?

stormi commented 3 years ago

We can close. It's already available in current update candidate for sm and I've already got a ticket to track its release.

xcp-ng / xcp