Tapdisk is just palin not good as a storage control mechanism, IMO. There's only so much you can pull out of it.

@gustavoninetyone -- it's not on the supported hardware list, hence highly unlikely. See Olivier's response near the top of this category to see what GPUs are supported.
-=Tobias

@olivierlambert Indeed. NVIDIA in particular is bent on your having to license any sort of vGPU technology and it would not surprise me to see even passthrough leveraged at some point in the future. There are already restrictions on being able to make use of Quadro features, for example, of you don't have licenses.

Also, note that you need one video board reserved to run the native OS (XCP-ng) dom0 instance itself, so the server has to effectovely have at least two graphics boards such that one can be used as a GPU.

@gsrfan01 Not sure that was ever officially supported, though I did implement a direct connection to a VM on XenServer with better results than with the standard process. You're right, it may or may not work with much newer versions of XCP-NG/XS/CH.

@vsaad A PERC-6 is pretty old technology. Getting in the 50 MB/sec I/O range seems pretty good and some of the limitations will be on the disks, themselves. You might try running "iostat -x" while the Crystal Mark test is running to see if anything saturates, like the CPU, or if you get high wait states or other tell-tale signs,

And from the CLI:

1. xe host-list (to get the UUID of the host)
2. xe pool-eject host-uuid=<host_UUID>

@daninmanchester Yes, a mine field is about right. Super good ou have made so much progress!

@mjtbrady That seems right, because the Docker instanceis independent and internal to the VM that otherwise is part of the XCP-ng networking structure and wouldn't have the necessary access permissions on it's own.

@daninmanchester I would think Docker is involved, as well. I was going to suggest to create a "standard" test VM ans see if you can connect storage to it. If so, that would put the blame on something specific to the VM that has that Docker container.

@HeMaN Yes, if I recall correctly, in the /etc/exports file. the full path should be specified and then "exportfs -a" should be issued to refresh the export list.
I just noticed your error message doesn't include the /export directory in front:
mount.nfs: access denied by server while mounting 192.168.11.60:/Backups

@daninmanchester Hmmm...maybe an NFS V3 vs. V4 support issue? Could you provide the full output of "showmount -e 192.168.11.60" ?

@daninmanchester What does showmount list for the server exports? Is the local 192.168.X.X subnet properly exported from the NFS server? Check the /etc/exports files on the NFS server and make sure that directory is listed. BTW, do you have any sort of multipathing implemented?

@daninmanchester Run the "showmount" comand against your NFS server to see if you have access permissions. https://www.thegeekdiary.com/showmount-command-examples-in-linux/

@Andrew Thank you for that, much appreciated. Although I was aware of this process for SSD drives, I did not know that spinning disks had become that much smarter in the interim (~40 years!). But in any case, raw drives are very powerful if you have decent code to access them and the overhead can be appreciably less than with formatted drives.

@olivierlambert said in SMAPIv3 - Feedback & Bug reports:

You need to get rid of SMAPIv1 concepts If you meant "iSCSI block" support, the answer for right now: no.

It's a brand new approach so we'll take time to find the best one, to avoid all the mess that had SMAPIv1 on block devices (non thin, race conditions etc.)

I think the next big "device type" support might be raw (passing a whole disk without any extra layer to the guest).

Ages ago (in the 1980s), I experimented with raw disk I/O on VAX systems using QIO calls. Yes, it's fast, but also doesn't take bad block or deteriorating disk sectors into account. I can't recall offhand if there way a way to at least update bad block lists or if you had to start from scratch.

Are there better mechanisms these days to handle such things as read/write errors and re-allocation to good blocks if bad blocks are detected on a running system?

Reference: https://www.tech-insider.org/vms/research/acrobat/7808.pdf

@mauzilla In the past, I have run into this problem when introducing a new host into a pool and the primary management interface was picked up on the non-primary bond. To properly add a new host to a pool, only the primary management interface should be configured on the host and correspond to the subnet of the primary on the pool master. Just mentioning this because I ran into it before, even if it turns out not t pertain to your specific case.

Also, I have run into a host before - the exact same hardware as another - where one Ethernet NIC showed up in a different order than on the other server -- even though it was on the same card! I had to use the interface-rename application to switch it around and make it match.
Strange things happen.