Support for Windows failover clustering

K

khblenk

Member
Jul 2, 2020
11
1
8
46
I'm attempting to install a Windows Server 2022 Failover Cluster within my Proxmox environment to provide additional protection against operating system failures and to enable rolling updates for SQL Server.
I use a Fibre Channel SAN, with the LUNs presented on the Proxmox host.

The LUNs are mounted into the guest systems as follows (for example):
Code: 
scsi2: /dev/mapper/sqlcluster-quorum,cache=none,shared=1,aio=native,discard=on,serial=QM000000005
scsihw: virtio-scsi-pci

Unfortunately, Windows does not accept the disks with the message (translated from German):
The physical disk ... does not support the Query Data (VPD Descriptor according to SCSI Page 83h) required for failover clustering. Status: The request is not supported.

The Qemu drivers and guest tools are installed on Windows.

Are there any settings that can be adjusted to support VPD? Are there any alternative methods of integration (other than iSCSI), such as virtual WWNs?
 
Hello. Have you found some solution for that ?
PS: i need to do the same, but with ceph and without a FC SAN.
 
Hi khblenk
Vital Product Data (i.e., VPD) page 0x83 is the "Device Identification" page (see the SCSI Primary Commands specification). It is a table that contains descriptors that describe the SCSI device and transport protocols applied to a logical unit.

Basic VPD support does not unlock support for Windows Failover Clusters. The next hurdle would be support for persistent reservations, which requires strict management of initiator port identification bindings.

Note that QEMU has enough functionality to do full passthough. If you are using SCSI-compliant storage, installing a Windows 2022 Failover cluster and passing storage validation is possible. As one data point, it works without issue with Proxmox on Blockbridge (using raw device paths). However, we natively support iSCSI, which simplifies things significantly.

I'm unsure how you would get FC storage to work easily in this application. Managing the combination of FC, multi-pathing, and persistent reservations is complicated.

@f.cuseo
Windows failover clusters require robust support for SCSI persistent reservations: CEPH, NFS, and LVM are not options. Emulated reservation support may be an option in some cases (perhaps using the discontinued CEPH iSCSI Gateway). However, given the complexity and risk, I would proceed with extreme caution.

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
Last edited:
khblenk said:
I'm attempting to install a Windows Server 2022 Failover Cluster within my Proxmox environment to provide additional protection against operating system failures and to enable rolling updates for SQL Server.
I use a Fibre Channel SAN, with the LUNs presented on the Proxmox host.

The LUNs are mounted into the guest systems as follows (for example):
Code: 
scsi2: /dev/mapper/sqlcluster-quorum,cache=none,shared=1,aio=native,discard=on,serial=QM000000005
scsihw: virtio-scsi-pci

Unfortunately, Windows does not accept the disks with the message (translated from German):
The physical disk ... does not support the Query Data (VPD Descriptor according to SCSI Page 83h) required for failover clustering. Status: The request is not supported.

The Qemu drivers and guest tools are installed on Windows.

Are there any settings that can be adjusted to support VPD? Are there any alternative methods of integration (other than iSCSI), such as virtual WWNs?
Click to expand...

Hi!
Change the disk controller (scsihw) to the default(LSI ... ),
and do not use "discard=on" on disks, it will work.

I also do not recommend to use any virtio-* emulation for Windows.
 
Last edited:
bbgeek17 said:
Hi khblenk
Vital Product Data (i.e., VPD) page 0x83 is the "Device Identification" page (see the SCSI Primary Commands specification). It is a table that contains descriptors that describe the SCSI device and transport protocols applied to a logical unit.

Basic VPD support does not unlock support for Windows Failover Clusters. The next hurdle would be support for persistent reservations, which requires strict management of initiator port identification bindings.

Note that QEMU has enough functionality to do full passthough. If you are using SCSI-compliant storage, installing a Windows 2022 Failover cluster and passing storage validation is possible. As one data point, it works without issue with Proxmox on Blockbridge (using raw device paths). However, we natively support iSCSI, which simplifies things significantly.

I'm unsure how you would get FC storage to work easily in this application. Managing the combination of FC, multi-pathing, and persistent reservations is complicated.

@f.cuseo
Windows failover clusters require robust support for SCSI persistent reservations: CEPH, NFS, and LVM are not options. Emulated reservation support may be an option in some cases (perhaps using the discontinued CEPH iSCSI Gateway). However, given the complexity and risk, I would proceed with extreme caution.

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
Click to expand...
Thank you for your support. We don't use Windows Failover cluster directly, but we need to setup a cluster for one of our customers.
I will take a look at blockbridge, but i don't know if is possible to add servers and license costs :(
We only need less than 8Tbyte of usable space, but with the maximum availability, and better if we can backup the whole windows vms with PBS.
 
f.cuseo said:
We don't use Windows Failover cluster directly, but we need to setup a cluster for one of our customers.
Click to expand...
Understood. To clarify, I was speaking of running a nested Windows Failover cluster within PVE.

@emunt6

Thanks for your contribution. However, OP asked about Windows Server 2022. From what I understand, Windows no longer supports drivers for older LSI controllers. We covered this in our technote series on the Windows 2022 server: https://kb.blockbridge.com/technote...part-1.html#windows-server-2022-driver-status

Note that this technical series also covers the significance of Virtio's performance and efficiency gains.
I cannot attest to the correctness or completeness of SCSI passthrough on those older controllers. Regardless, OP must be confident in managing the SCSI initiator identities used for persistent reservations, as they are essential to correctness and integrity.

Lastly, it's worth clarifying that Windows cluster compliance validation test referenced in my original reply was run with virtio-scsi. So, we can confirm that it works!

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
  • Like
Reactions: emunt6
bbgeek17 said:
Understood. To clarify, I was speaking of running a nested Windows Failover cluster within PVE.

@emunt6

Thanks for your contribution. However, OP asked about Windows Server 2022. From what I understand, Windows no longer supports drivers for older LSI controllers. We covered this in our technote series on the Windows 2022 server: https://kb.blockbridge.com/technote...part-1.html#windows-server-2022-driver-status

Note that this technical series also covers the significance of Virtio's performance and efficiency gains.
I cannot attest to the correctness or completeness of SCSI passthrough on those older controllers. Regardless, OP must be confident in managing the SCSI initiator identities used for persistent reservations, as they are essential to correctness and integrity.

Lastly, it's worth clarifying that Windows cluster compliance validation test referenced in my original reply was run with virtio-scsi. So, we can confirm that it works!

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
Click to expand...

There is another option using "VIRTIO-DISK(scsi) + Virtual-Disk(VDHX) + Microsoft SQL Cluster"
- VMs main disk is virtio-based scsi, after add VHDX disk-image on top, use this virtual-disk for cluster-disk.
( diskmanager > Action > Create VHD > VHDX )
Screenshot from 2024-05-04 11-29-10.png
- You don't need to install the "HyperV" role.
- You can resise the VHDX image with diskpart
Code: 
diskpart
select vdisk file="Z:\Disk.vhdx"
expand vdisk maximum=<size in MB>
list volume
select volume <number>
extend
exit


This solution bypass the virtio problem "SCSI-3 Persistent Reservation" that is missing from Qemu, but it requires for MS SQL.
 
Last edited:
emunt6 said:
This solution bypass the virtio problem "SCSI-3 Persistent Reservation" that is missing from Qemu, but it requires for MS SQL.
Click to expand...
If I understand your post correctly, this configuration moves your HA into application (SQL). In many cases this is the best approach, especially if the application is natively capable of this functionality.

Good luck

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
emunt6 said:
There is another option using "VIRTIO-DISK(scsi) + Virtual-Disk(VDHX) + Microsoft SQL Cluster"
- VMs main disk is virtio-based scsi, after add VHDX disk-image on top, use this virtual-disk for cluster-disk.
( diskmanager > Action > Create VHD > VHDX )
View attachment 67519
- You don't need to install the "HyperV" role.
- You can resise the VHDX image with diskpart
Code: 
diskpart
select vdisk file="Z:\Disk.vhdx"
expand vdisk maximum=<size in MB>
list volume
select volume <number>
extend
exit


This solution bypass the virtio problem "SCSI-3 Persistent Reservation" that is missing from Qemu, but it requires for MS SQL.
Click to expand...
Just a question: you create VHDX image on which "physical" drive ? Having 2 different windows servers, you need a shared unit drive ?
 
f.cuseo said:
Just a question: you create VHDX image on which "physical" drive ? Having 2 different windows servers, you need a shared unit drive ?
Click to expand...
I think this is the main question. How must the "shared" disk be created / configured in the configuration of the VMs? I am a total Proxmox beginner and I have just tried to use VirtIO SCSI with different Formats and Options but the storage will not be available in Windows Failover Cluster Manager. :-(
 
On Vmware it is straightforward to create a shared disk to build up an environment for Microsoft Failover Cluster. Simply create a vmdk (Diskfile) with Thick provision and add a SCSI Controller of type "VMware Paravirtual" to both VMs you want to use for the Cluster and connect the disk you created in the step before to this controller. Set the option "Shared Usage" to "Virtual" and you are done.

It would really nice if there would a similar solution for Proxmox. I know it is not really a solution for a productive environment but it allows for example update of the Windows servers and reboot one of them without interruption of the services.
 
emunt6 said:
There is another option using "VIRTIO-DISK(scsi) + Virtual-Disk(VDHX) + Microsoft SQL Cluster"
- VMs main disk is virtio-based scsi, after add VHDX disk-image on top, use this virtual-disk for cluster-disk.
( diskmanager > Action > Create VHD > VHDX )
View attachment 67519
- You don't need to install the "HyperV" role.
- You can resise the VHDX image with diskpart
Code: 
diskpart
select vdisk file="Z:\Disk.vhdx"
expand vdisk maximum=<size in MB>
list volume
select volume <number>
extend
exit


This solution bypass the virtio problem "SCSI-3 Persistent Reservation" that is missing from Qemu, but it requires for MS SQL.
Click to expand...
Hello emunt6.
Can you explain better all the steps needed and if can be used in a production environment ?
 
If you add the SSD flag to SATA and IDE HDDs, they will be recognized as S2D disks.
HyperV's virtual SCSI controller supports SCSI Page 83h.
VMWare's VMSCSI does not support it, just like Virt-SCSI.
 
  • Like
Reactions: fireon
Hi,

We solved it in one of our clients with the following conf, we import the machine from a VMware Cluster. SATA only allows 6 disks on machine.

Code: 
agent: 1
bios: seabios
boot: order=virtio0
cores: 4
cpu: x86-64-v2-AES
machine: pc-i440fx-9.2+pve1
memory: 32768
meta: creation-qemu=9.2.0,ctime=1750332851
net0: virtio=00:50:56:a3:29:1b,bridge=vlan303
net1: virtio=00:50:56:a3:6b:72,bridge=vlan27
ostype: win11
scsi0: pool-vms:vm-110-disk-1,cache=writeback,size=400G,ssd=1,serial=110-disk1
scsi1: pool-vms:vm-110-disk-2,cache=writeback,size=800G,ssd=1,serial=110-disk2
scsi2: pool-vms:vm-110-disk-3,cache=writeback,size=400G,ssd=1,serial=110-disk3
scsi3: pool-vms:vm-110-disk-4,cache=writeback,size=400G,ssd=1,serial=110-disk4
scsi4: pool-vms:vm-110-disk-5,cache=writeback,size=400G,ssd=1,serial=110-disk5
scsi5: pool-vms:vm-110-disk-6,cache=writeback,size=400G,ssd=1,serial=110-disk6
scsi6: pool-vms:vm-110-disk-7,cache=writeback,size=300G,ssd=1,serial=110-disk7
scsi7: pool-vms:vm-110-disk-8,cache=writeback,size=400G,ssd=1,serial=110-disk8
scsi8: pool-vms:vm-110-disk-9,cache=writeback,size=400G,ssd=1,serial=110-disk9
scsi9: pool-vms:vm-110-disk-10,cache=writeback,size=400G,ssd=1,serial=110-disk10
scsihw: virtio-scsi-single
smbios1: uuid=421eda8e-f122-9995-1619-bf37de0d7a7a
snaptime: 1750685498
sockets: 1
vga: virtio
virtio0: pool-vms:vm-110-disk-0,cache=writeback,iothread=1,size=120G,serial=system

Best regards!
 
You must log in or register to reply here.
Top Bottom