Operators from our Vates Pro Support
Hi,
We have similar deployments (and they are more and more common with Broadcom leaving a huge void even in this context).
There's probably some improvements possible, worth thinking about it. Have you already contacted Vates to get potential more advanced discussions about this use case?
@florent is working on various improvements yes.
Yes it is and it's pretty logical since you don't have to wait confirmation before getting the block actually written on the drive.
Nothing very specific, sync vs async should be the biggest change
Hi,
We can't help on outdated XO commits, it's impossible to do so, see https://docs.xen-orchestra.com/community#report-a-bug. Please update to the latest one and report if you still have the issue, thanks!
edit: note that the error is likely not an XO side here, we got a HTTP 500.
Indeed, sync is likely the cause of that. And since you have to write the RAM, it can be a lot of GiB for big VMs.
You can experiment to disable sync temporarily and test again.
Note that a future improvement will be to save the VM RAM while the VM is running (instead of pausing it), reducing the "downtime". But this won't change the fact you must write the RAM somewhere, and this takes time.
Have you checked:
And for Pfsense: https://docs.xcp-ng.org/guides/pfsense/#3-disable-tx-checksum-offload
