PowerStore block storage can also be presented directly to Hyper-V guest VMs using the following methods:
In-guest iSCSI: Configure the host and VM network so the VM can access PowerStore iSCSI volumes through a Hyper-V host or cluster network.
- Configure in-guest iSCSI on the VM. The setup is similar to iSCSI on a physical host.
- MPIO is supported on the VM if multiple paths are available to the VM, and the multipath I/O feature is installed and configured.
Physical disks: Physical disks presented to a Hyper-V VM are often referred to as pass-through disks. A pass-through disk is mapped to a Hyper-V host or cluster, and I/O access is passed through directly to a Hyper-V guest VM. The Hyper-V host or cluster has visibility to a pass-through disk and assigns it a LUN ID, but does not have I/O access. Hyper-V keeps the disk in a reserved state. Only the guest VM has I/O access.
- Use of pass-through disks is a legacy configuration that was introduced with Hyper-V 2008.
- Pass-through disks are no longer necessary because of the feature enhancements with newer releases of Hyper-V (generation 2 guest VMs, VHDX format, and shared VHDs).
- Use of pass-through disks is now discouraged, other than for temporary or specific use cases.
In-guest iSCSI and pass-through disk use cases
PowerStore arrays support in-guest iSCSI and pass-through disks (direct-attached disks) mapped to guest VMs. However, we do not recommend using direct-attached storage for guest VMs as a best practice unless a specific use case requires it. Typical use cases include:
- Performance: Direct-attached disks bypass the host server file system and so offer slightly better performance than a VHD or VHDX. There is no significant difference in performance between a direct-attached disk and a virtual hard disk for most workloads.
- Clustering: VM clustering on legacy Hyper-V platforms require the use of direct-attached disks. Shared VHDs are preferred for VM clustering with Server 2012 R2 and newer.
- Troubleshooting: Use of a direct-attached disk can be helpful if you must troubleshoot the I/O performance of a volume and isolate it from all other servers and workloads.
- Custom snapshot or replication policy: It might be necessary in some use cases to apply a custom PowerStore snapshot or replication policy to a specific disk (volume).
- The preferred method is to place a virtual hard disk on a dedicated cluster shared volume (CSV) in a one-to-one configuration. Then, apply PowerStore snapshots and replication to the CSV.
- Capacity: Legacy VHDs support a maximum size of 2 TB. VHDX supports a maximum size of 64 TB. If a data volume will exceed these limits, you might be required to use in-guest iSCSI or a pass-through disk. The maximum supported size of a direct-attached disk is a function of the VM operating system.
In-guest iSCSI and pass-through disk storage limitations
- Native Hyper-V Snapshots: The ability to perform native Hyper-V snapshots is lost. However, the ability to use PowerStore snapshots of the underlying volume is unaffected.
- Complexity: Use of direct-attached volumes increases complexity, requiring more management overhead.
- Mobility: VM mobility is reduced due to creating a physical hardware layer dependency.
- Scale: Each pass-through disk consumes a LUN ID on each host in a Hyper-V cluster. Extensive use of pass-through disks quickly becomes impractical and unmanageable at scale on a Hyper-V cluster. Use pass-through disks sparingly if they are required.
- Differencing Disks: The use of a pass-through disk as a boot volume on a guest VM prevents the use of a differencing disk.
Note: Legacy Hyper-V environments that are using direct-attached disks for guest VM clustering should consider switching to shared virtual hard disks when migrating to a newer Hyper-V version.