If you would like to read the other parts in this article series please go to:
VSID
VSID, sometimes referred to as the Virtual Subnet ID, is assigned to customer virtual machines. This is different from the VLAN ID, which is assigned from the property page of a virtual machine. A virtual machine participating in Hyper-V Network Virtualization must be assigned with a VSID, not a VLAN ID. You cannot assign the VLAN ID to a virtual machine if it is already configured with a VSID, and vice-versa. Traditional VLAN ID range starts from 1 to 4095, whereas the VSID range is from 4096 to 16,777,214. Hyper-V Network Virtualization separates the customer virtual machines using the VSIDs assigned to them. The VSID assignment can be done automatically by using either the SCVMM, or manually using the HNV PowerShell cmdlets. If you need to assign the VSID to a virtual machine using PowerShell, use the Set-VMNetworkAdapter cmdlet.
The Set-VMNetworkAdapter is not a new PowerShell cmdlet designed to support Hyper-V Network Virtualization implementation, but it does support “VirtualSubnetID” parameter which helps you assign VSID´s to virtual machines. To assign VSID using Set-VMNetworkAdapter, execute the below commands on both the Hyper-V hosts:
On Hyper-V Host1
- Get-VMNetworkAdapter -VMName Blue1 | where {$_.MacAddress -eq “00155D013202”} | Set-VMNetworkAdapter -VirtualSubnetID 6001
- Get-VMNetworkAdapter -VMName Blue4 | where {$_.MacAddress -eq “00155D013203”} | Set-VMNetworkAdapter -VirtualSubnetID 6002
- Get-VMNetworkAdapter -VMName Red1 | where {$_.MacAddress -eq “00155D013204”} | Set-VMNetworkAdapter -VirtualSubnetID 6005
On Hyper-V Host2
- Get-VMNetworkAdapter -VMName Blue2 | where {$_.MacAddress -eq “00155D013205”} | Set-VMNetworkAdapter -VirtualSubnetID 6001
- Get-VMNetworkAdapter -VMName Blue3 | where {$_.MacAddress -eq “00155D013206”} | Set-VMNetworkAdapter -VirtualSubnetID 6001
- Get-VMNetworkAdapter -VMName Red2 | where {$_.MacAddress -eq “00155D013207”} | Set-VMNetworkAdapter -VirtualSubnetID 6001
The first, second and third commands are executed on the Hyper-V Host1 because Blue1, Blue4 and Red1 virtual machines are running on the Hyper-V Host1. Please refer to the HNV design that we are using for the purposes of this article series in Part 1. The fourth, fifth, and sixth commands are executed on the Hyper-V Host2 because Blue2, Blue3 and Red2 virtual machines reside on the Hyper-V Host2.
The above commands make sure that these virtual machines are isolated completely. They are never allowed to talk to a virtual machine, which is in a different VM Network/RDID. It is important to note that even though the Blue1 and Blue4 virtual machines are using different VSID, they are still part of the same RDID/VM Network. Since these virtual machines are part of the same RDID/VM Network, they can communicate with each other without requiring any further configuration. Blue1 and Blue4 virtual machines cannot communicate with the Red1 and Red2 virtual machines because the Red1 and Red2 virtual machines belong to a different RDID/VM Network. Hence, RDID/VM Network and VSID assignment play an important role in isolating the customer virtual machines on a shared IaaS cloud.
Note that the VSID is assigned to the “virtual network adapter” of a virtual machine. A virtual machine can have multiple virtual network adapters connected to it. You must assign the VSID to the correct virtual network adapter of the virtual machine. In the previous commands, we have used the Get-VMNetworkAdatper PowerShell cmdlet to filter the virtual machine by the MAC Address and then assign the VSID to the correct virtual network adapter. There is no need to use the Get-VMNetworkAdapter PowerShell cmdlet if all the virtual machines have only one virtual network adapter configured. In that case, you can simply run the Set-VMNetworkAdapter command with the –VirtualSubnetID parameter to assign the VSID.
If you try to assign VLAN ID to a virtual machine for which a VSID ID is already assigned, you will get an error message as shown in the below screenshot:
Figure 1
Similarly, if a virtual machine is already configured with a VLAN ID and if you try to configure the VSID, you will get an error message as shown in the below screenshot:
Figure 2
The error does not specifically say that the VLAN ID is already assigned to the virtual machine. Instead, the error message indicates that the operation has failed while applying the switch port settings. It is therefore important to make sure that the virtual machines, participating in Hyper-V Network Virtualization, are not already assigned with a VLAN ID.
Note:
Virtual machine will not participate in Hyper-V Network Virtualization if the VSID´s are not assigned to them. In other words, a virtual machine assigned with a VSID 0 will be ignored by the WNV module.
To make sure that virtual machines have been assigned with a VSID, you can use the Get-VMNetworkAdapter PowerShell cmdlet, as shown in the below screenshot:
- Get-VMNetworkAdapter * | FT VMName, MACAddress, VirtualSubnetID –Auto
Figure 3
As you can see in the above screenshot, virtual machines (Red1, Blue4 and Blue1) are assigned with a unique VSID. Execute the same command on the Hyper-V Host2 to make sure that the result matches with the HNV design.
The VSID information, populated in the Lookup Table for virtual machines, must match with the VSID assigned to the virtual machines. In case VSID does not match, the packet will be dropped by the WNV Module. I will talk more about the logic used by the WNV module to look for the destination virtual machine in the final part of this article series.
At this stage,
- You have configured the isolation for the virtual machines by using multiple WNV components.
- You used the RDID, VM Network and VSID to isolate the customer virtual machines.
- You can configure the virtual machine to use the IP addresses. For example, you can configure Red1 and Red2 virtual machines to use the same IP Address, and they will not conflict.
Summary
In this part, we learned how the VSID plays an important role in isolating the customer environment from other customers, as well as how the VLAN ID is different from the VSID. In the next part of this article series, we will learn about the Lookup Table. Without the Lookup Table, it wouldn’t be possible for the WNV Module to locate the virtual machines running on local/remote Hyper-V Hosts. In the next post of this article series, we are going to closely look at the Lookup Table, as well as the logic used by the WNV module to look for the destination virtual machines running either on local or remote Hyper-V hosts.
I would recommend reading other parts of this article series to make sure you are aware of the WNV module components, which have been explained throughout this article series.
If you would like to read the other parts in this article series please go to:
