Production volumes are read-only in diskpart.exe at proxy server

[woifgaung]

Hello!

When production storage volumes (VMFS) are presented to a Veeam proxy host, these disks are visible in disk management and diskpart.exe. More often I see these disks are marked as read-only in diskpart.exe. This is a problem when it comes to direct storage restore. But from a security perspective it would be not bad idea, although it is a easy task to change mode to writeable.

I would be interested, if this is done be Veeam software? From my experience this behavior seems to be since about v10.

Best Regards
Wolfgang

[Andreas Neufert]

We are fully managing this within the software. Do not touch.
For example if you bring the disk online and you have as well automount enabled, then Windows write a signature and the datastore goes offline.

Btw. Direct Storage (SAN) is one of the slowest ways to restore as any (sequential) block write has to be coordinated through vcenter.
Suggest to use HotAdd or NBD for restore.

[woifgaung]

Thanks for your answer, Andreas!

I cannot fully agree when you say direct SAN restore is one of the slowest. I agree when VMDK is lazy-zeroed. But with eager-zeroed, direct SAN is most often the fastest transport mode for restore. I tried to find some detailed information from VMware for direct SAN restore traffic flow, but couldn't find anything. Do you have some links to share?

[Andreas Neufert]

You can search for the VDDK kit documentation.

I can just share what customer tests told me. And as well you can not compare other products processing with Veeam.
DirectSAN need the vCenter coordination + do syncronous processing. All is handeled through the VMware VDDK kit. This has some overhead.

Veeams HotAdd processing do asynconous processing and us a direct approach. Depending on controller load this restore can be 2-3x faster.

[woifgaung]

Found some information on direct SAN restore in Virtual Disk Development Kit Programming Guide (https://vdc-download.vmware.com/vmwb-re ... -guide.pdf) on page 123:

SAN transport is not always the best choice for restores. It offers the best performance on thick disks, but the worst performance on thin disks, because of round trips through two disk manager APIs, AllocateBlock and ClearLazyZero.

Thanks Andreas for your imput!

[Andreas Neufert]

Even at standard VDDK processing tests have shown that with all optimizations and correct disk type the SAN transport was not always the fastest option.

But with Veeam because of the async processing in HotAdd can be way faster. (Direct NFS and Backup from Storage Snapshot uses async processing and are usually faster).