SMAPIv3 Zvol odd behavior on XCP-ng pools
-
Re: First SMAPIv3 driver is available in preview
-
When adding a 2nd server to a pool, the zvol SR on 2nd server reports 0 bytes available on empty SR.
I have 2 new servers with fresh installs of XCP-ng 8.3. I have installed the zvol driver on both servers. As standalone servers, the new SR on each server shows a capacity of 19TB. If I create a new pool out of the 2 servers, the poolmaster shows the proper available space on its local zvol SR, but the second server's SR reports a total capacity of 1 byte with 1 byte used leaving 0 bytes available. Changing the poolmaster and unplugging/plugging the SR seems to fix the reporting. On a side note, creating the zvol SR on the second server after joining a pool shows the same behavior regarding the reporting of 0 bytes available. -
Unplugging the zvol SR causes the whole zfs pool to export, requiring reimporting the zfs pool manually before repairing/plugging the SR. This behavior applies to standalone servers too.
-
Removing a server from the pool causes the server's zvol SR to be forgotten, requiring the SR to be recreated.
-
Adding a server to a pool causes the zfs pool export as well, and while it does reimport automatically, all the datasets within the pool are unmounted obviously during this time. I am not sure of the implications of this if for instance VMs are running with their disks on the affected SR as I have not tested this.
-
Possibly out of scope, but if I want an encrypted dataset, the OS does not load the key automatically at boot, which I can address with a systemd service. However, this would not address the whacky behavior noted above with the exporting/importing of the zfs pool whenever an SR is unplugged or a server is added/removed from a pool, which then requires manual intervention to load the key, mount the dataset, and replug the SR if affected. I have an existing 8.2 server that is handling an SR on an encrypted dataset without issue using the older zfs driver.
Does XCP really need to be touching the ZFS pool when doing anything other than the initial pool creation? I feel this could be really bad potentially.
-
-
Upon further testing, it seems that initiating a rescan of the 0 byte SR fixes the size issue. However, I should not be having to do this but at least it appears to be more easily dealt with than I previously assessed.