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>

@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.

And from the CLI:

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

@BradyS Probably this is due to incompatible BIOS settings, such as C states, turbo mode, etc. Run "xe host-cpu-info" on each host to compare the two host settings. Also, make sure the firmware and update levels are all the same as those can also affect the CPU masks.

@tekwendell Do you also have C states enabled in your BIOS settings? Maybe these articles might help:

https://blogs.mycugc.org/2019/03/07/a-tale-of-two-servers-how-bios-settings-can-affect-your-apps-and-gpu-performance/

https://blogs.mycugc.org/2019/04/30/a-tale-of-two-servers-part-2-how-not-only-bios-settings-but-also-gpu-settings-can-affect-your-apps-and-gpu-performance/

It certainly sounds like a BIOS setting is responsible. Also, turbo mode will not always turn on unless the load is pretty high, from what I hav seen.

@mietek Depends on the VIF that the VM had in the template, I would imagine. Easy enough to change once you have your new VM. Worst case, create a new template.
I have seen NICs randomly change order on hosts in the past - scary stuff!

@mietek As to changing the NIC order in a template, not as far as I know. That is a host/pool configuration setting.

@Kajetan321 I'm guessing there is an incompatibility issue. Again, the CPUs have to be quite similar for this to work and the BIOD settings have to also match closely. Sorry for your hassles, but try finding a more compatible CPU. Citrix at least used to have a compatibility list though it's not updated as often as one would want. See also this article for some useful info, as old as it is. Some of these utility may no longer exist, alas.
https://support.citrix.com/article/CTX127059/understanding-heterogeneous-cpu-pooling-in-xenserver

@jivanpal Right; I simply meant you could start using these to track from this point onward. Also other options, like Cacti, MRTG, etc.