The XVA import seems to get to about 4TiB and then crashes (came in the morning to a white page, chrome tab crash?) and XO appears to be unresponsive. Restarting the VM allows things to resume back to normal.
Since 10TiB XVA's appear to be problematic for XO when it is this large for as slow as the backing storage is (10-20MBps to RAIDZ6 on FreeNAS9.10), what other methods are there to import larger XVA's to XCP-ng?
Is there an upper limit to the size that an XVA can be imported via XO? If there is, what other ways can I import a 10TiB VM & 5xVHD XVA?
I have a pool of 4 older E5545 servers in a Twin^2 SuperMicro chassis, three of which I have powered down for heat reasons and power usage while swapping out 120VAC UPS' for a 208VAC UPS. After starting to shut down some of the other nodes, and leaving the master node up, I noticed that the stats for the two SR's they shared, a SMB and iSCSI SR, started to no longer have stats in XO despite still obviously communicating with them.
I assume its stuck in syncIOwait to gather the states from the powered down nodes but never recovers from this state.
There is JS console errors as well (Chrome 75, Win10 64, XO 5.43, XCP-ng 7.6):
Uncaught (in promise) t
code: 18
data: {objectId: "c60d7e6f-8cbf-4ffd-9241-9938c3162f38"}message: "host offline"name: "t"stack: "t: host offline at t.<anonymous> (http://xen-orchestra/index.js:1:3602096) at g (http://xen-orchestra/index.js:1:223360) at Generator._invoke (http://xen-orchestra/index.js:1:223148) at Generator.e.<computed> [as next] (http://xen-orchestra/index.js:1:223539) at r (http://xen-orchestra/index.js:1:213429) at http://xen-orchestra/index.js:1:213570 at new Promise (<anonymous>) at new t (http://xen-orchestra/index.js:1:413522) at t.<anonymous> (http://xen-orchestra/index.js:1:213364) at t.<anonymous> (http://xen-orchestra/index.js:1:3602652)"__proto__: i
I'm not sure what I could do to help it other than spin up the other three nodes just to regain the stats (trying to monitor testing servers to spec out final homes).
@olivierlambert I would be willing to be a testing help for this. I have a few 6TB WD Golds I could throw each onto four older Fat Twin^2 nodes and do maybe passthrough for the OSD's (slightly esoteric and small but could give baselines if E5645's are still supported).
Currently they're just "collecting dust" inside of a chassis and use to be part of a 6x6TB RAIDZ2 ZFS pool that was retired for a 10x10TB RAIDZ2 pool (general storage + endpoint backups).
@ronan-a what call is causing such a deep call stack in tapdisk? All of them look to be "unknown," including its direct parent after tapdisk itself.