Veeam for Proxmox, restoring in QCFS2 with wrong aio + wrong file format

[nimda]

Two bugs:
1. On Proxmox with OCFS2 file system, the worker is created in QCOW2 format with "aio=io_uring" and is therefore not executable. It must be done with "aio=threads" to be executable.
(For the cloud-init disk, aio=uring is OK. On Proxmox with XFS file system, the worker is created in QCOW2 format with "aio=io_uring" for all disks, which is a working configuration)
2. In cross platform restore mode, the VMWare VM is restored in RAW format on Proxmox (xfs or ocfs2) despite the disk type setting QCOW2.
Veeam Support - Case # 07442446 - Bugs in "Veeam for Proxmox"

[nimda]

I would like to be a little more precise:
"(For the cloud-init disk, aio=uring is OK. On Proxmox with XFS file system, the worker is created in QCOW2 format with "aio=io_uring" for all disks, which is a working configuration)"
Tis is valid only for the worker. The on XFS created VMs also need to have aio_threads to be executable, as it is on OCFS2.

Additional info:
The Proxmox has an FC-SAN distributed storage in multipath config, mounted as directory folder. This directory folder is selectable from the Veeam side as storage where the VMs are able to be restored on.

[PTide]

Hi,

Thank you for submitting the bug #2, good catch!

As for #1 - AFAIK, OCFS2 is not officially supported by Proxmox, so I cannot make any promises on how fast we are going to implement support for io_threads.

Cheers

[nimda]

Unfortunately, I have to correct you "...implement support for io_uring." The missing aio type is "threads" , see m first post: "It must be done with "aio=threads" to be executable."

The easiest way to solve #1 could be to have a new option "aio" for the worker AND additionally a new option "aio" for the cross platform restore. I am happy to test your test versions for #1 in our real environment.

[PTide]

yes, that was a typo on my part

Thank you!

[nimda]

Update:
The error for the worker is still there with the latest updated plugin v12.1.1.1024.

I mean since Veeam is automatically using ocfs2 for its workers (depending on the storage format of the target hardware), they also should provide the "aio" option which is needed to make their own workers running. Alternatively, they find a way for automatic selection of a fitting aio type (depending on the storage format of the target hardware).

To proove that it is a bug, I run a script, which tries to append ",aio=threads" to the "ide2" line and the "virtio0" line to conf file WHILE the worker is being deployed. This results in a running worker.

[nimda]

Edit: Typo, "I mean since Veeam is automatically using ocfs2 for its workers..." I meant QCOW2 file format instead of of ocfs2.

QCOW2 is automatically choosen for the Veeam worker on OCFS2 file system and on XFS file system.

For the worker needed:
For QCOW2 and OCFS2 it must have aio=threads
For QCOW2 and XFS the default (aio=io_uring) is working

[nimda]

Update:
For RAW and OCFS2 it must have aio=threads

Remark:
RAW / QCOW2 = VM disk format
OCFS2 / XFS = file system format, on which the VMs ars running

[PTide]

Hi,

Well, the mentioned build does not include that fix as it's been dedicated to fixing a bunch of other issues.

Thanks!

[nimda]

Hi PTide,
thanks. Since Proxmox Kernel 6.5, aio=threads is needed for SAN (FC-) LUN, see https://forum.proxmox.com/threads/async ... ve.153439/

In my opinion it is only the lack of a aio configuration option for the Veeam worker and it should be the same as it exists in Proxmox for configuring the disks on creating VMs.

I hope that the next Veeam update will come soon with such an aio option for the worker. Additionally, I recommend an aio option for cross-platform restore functionality.

Best.