Introduction

Working as a StarWind Support engineer is sometimes tricky, as on certain occasions my colleagues and I have to deal with things that go far beyond supporting only the StarWind products. In many cases, it is closely connected with hypervisors, client’s software used in clustered VMs with their storage on StarWind HA disks.

Not so long ago I have come across a situation where the non-conventional use of StarWind disks has taken place, as per the client’s requirements. Instead of configuring pure Cluster Shared Volumes for the Microsoft Failover Cluster with VM’s VHDX disks on top of those CSVs, we had to introduce separate StarWind HA disks directly into the clustered VMs. To better understand the idea, below is the scheme demonstrating this approach.

Connecting StarWind HA disks directly to the clustered VMs

In my test environment, I am using Windows Server 2016 that is capable of hot-adding the network interfaces to the guest VMs.

As the main thing about configuring this is proper network setup for the VMs to be able to discover the storage provided by StarWind VSAN, I will consider the networking part of the setup, particularly manipulations with the Hyper-V switches that use the physical adapters dedicated to the iSCSI traffic.

For illustration purposes I will use two ways:

GUI;

Command line.

However, I prefer the latter.

Let’s start with GUI

From GUI, we need to add an external vSwitch in Hyper-V Manager using Virtual Switch Manager as demonstrated in the screenshot below:

When created, the new virtual switch shall be assigned a network interface:

Now, to PowerShell

If I do this using PowerShell, it will take me only a couple of lines of code to perform the same:

Import-Module Hyper-V $iscsilink = Get-NetAdapter | Where{$_.Name -like "*iscsi*"} New-VMSwitch -Name iscsiSwitch -NetAdapterName $iscsilink.Name -AllowManagementOS $true 1 2 3 4 5 Import - Module Hyper - V $ iscsilink = Get - NetAdapter | Where { $ _ . Name - like "*iscsi*" } New - VMSwitch - Name iscsiSwitch - NetAdapterName $ iscsilink . Name - AllowManagementOS $ true

I run this on both StarWind nodes if I want the setup to have paths to the storage from both nodes.

Next step is to add the newly created switch into the VMs.

The GUI way implies going into the VM’s settings, clicking on Add Hardware, and selecting Network Adapter to be added:

After this is added, I select the network adapter and assign the vSwitch, to which it is going to connected.

In PowerShell, type the following:

Add-VMNetworkAdapter -VMName Test1 -SwitchName iscsiSwitch -Name iSCSInet 1 Add - VMNetworkAdapter - VMName Test1 - SwitchName iscsiSwitch - Name iSCSInet

If you need more VMs to be processed, just list them separated with commas:

Add-VMNetworkAdapter -VMName Test1,Test2,Test3 -SwitchName iSCSInet -Name iSCSInet 1 Add - VMNetworkAdapter - VMName Test1 , Test2 , Test3 - SwitchName iSCSInet - Name iSCSInet

Sure thing, if you have only one VM, there won’t be any benefit of using PowerShell instead of GUI except for the reason of giving your adapter some custom name. If you compare the two network adapters in the picture below, you’ll definitely see the different names they have. The top one was created using GUI, while the bottom one was created from PowerShell.

After the networking part is done on the Hyper-V hosts, the VMs should be configured to have access to replicated StarWind storage, but it is out of the scope of my today’s post.

At some certain point, anyone reading this may come across the StarWind official documentation that instructs how to configure everything properly, and thus decides to reconfigure the setup by removing the direct connection of the StarWind storage to VMs. Here’s how this should be done then:

From GUI:

In the VM settings, select the network adapter to be removed and click on the Remove button.

From PowerShell, shoot the following:

Remove-VMNetworkAdapter -VMName TestVM -Name iSCSInet 1 Remove - VMNetworkAdapter - VMName TestVM - Name iSCSInet

VSAN from StarWind eliminates any need for physical shared storage just by mirroring internal flash and storage resources between hypervisor servers. Furthermore, the solution can be run on the off-the-shelf hardware. Such design allows VSAN from StarWind to not only achieve high performance and efficient hardware utilization but also reduce operational and capital expenses. Learn more about ➡ VSAN from StarWind.

Conclusion

Hope this information will be interesting for those following the path of experimenting with networking in non-conventional setups of the StarWind VSAN hyperconverged systems. As we see, Windows Server 2016 offers new possibilities for manipulating network settings for VMs in live environment, with certain features being easily done from both GUI and command line, and some options being available from command line only. Feel free to select the one you prefer and that suits your particular purpose.

Related materials:

Views All Time Views All Time 13 Views Today Views Today 41

Appreciate how useful this article was to you?

5 out of 5, based on 1 review 5 out of 5, based on 1 review

Loading... Loading...