VMware View advanced networking
The last few months I have been busy designing, building and testing a new VMware View solution for our own Support Center. In this Support Center we do support and system administration for some of our biggest clients. One of the challenges is the use of desktop hardware and the limited space of a call agent’s or administrator’s desk. Many of my colleagues support multiple client sites and need different PCs for each client. So in 2008 one of my respected colleagues thought of a great solution and advised to implement a VMware VDI solution.
The idea was to create a pool of virtual desktops for each client site and supply the call agents and system administrators with a standard physical desktop with which they can access one or more virtual desktops and do the standard office work (Word, Outlook, etc) at the same time. Saving space needed for all those desktops and minimizing heat, power, etc and improving the working conditions in the process.
We bought four DELL PowerEdge 2950 II’s with two quad core CPUs and 64GB of memory each and a DELL EqualLogic 5000E iSCSI SAN to build this all virtual VDI solution.
One of the biggest challenges was to separate all client networks, so we assigned VLANs to all of them. But this raised a new challenge as I discovered during the implementation. Because we assigned all client their own VLAN and there was no routing between them, how can we connect to the virtual desktops.
As you can see in the schema below or on page 32 of the VMware View Manager 3 Administrator guide the connection to the virtual desktop is initiated by the View Connection Server together with the VMware View agent. After selecting an available desktop a RDP connection is established directly between the VMware View client and the virtual desktop. In our situation, with separate VLANs this is impossible so I took a deep dive into the entrails of VMware View.
I quickly discovered that it is possible to disable the Direct desktop connection which forces the RDP connection to go through the VMware View Connection server. This way I could use the VMware View Connection server as a ‘firewall/proxy’ to the client VLANs when I connect the VMware View Connection server to all port groups/client VLANs. It took me some time to get this working because I had to establish communication between the VMware View Connection server and the VMware View agents which were in other VLANs. After some calls to a few colleagues and our VMware Field SE I found out that name resolution was the cause of my problems and after creating a host file (no DNS available) on all virtual (test) desktops it worked like a charm.
So thinking I was in the clear I confidently finished the configuration, quickly meeting my next challenge. As you can see in the schema above I created this with only three client VLANs in mind. Bummer! The VMware View Connection server is a virtual machine and I currently have six client VLANs (and counting) and as we all know a virtual machine is limited to four network interfaces.
Another call to one of my most talented ;-) colleagues helped me out again. He suggested to create a port group with VLAN ID 4095, this port group would then pass through traffic from all VLANs and leave the VLAN tag intact, and connect a single network interface on the virtual machine side and use Virtual Machine Guest Tagging (VGT mode). To get this working you need an Intel e1000 network interface in your virtual machine so I had to change the Operating system setting in the virtual machine options to Windows Server 2003 x64. Now that the Intel e1000 was available I added it to the virtual machine but no VLAN settings of any kind where available. After a few VMware KB articles and a lot of Google I found that I needed to install the proper Intel PRO /1000MT driver instead of the driver provided by the VMware Tools. By installing this driver you get a lot of advanced options including VLAN settings needed for Virtual Machine Guest Tagging.
After creating virtual network adapters for all client VLANs and assigning the correct IP addresses on it I got it working. YEAH! Victory at last.
It sounds a bit silly, creating virtual adapters on a virtual network interface in a virtual machine but in my opinion it can never get virtual enough ;-). Virtualization to the MAX!
Today I have a meeting with our VMware Field SE and I will ask him if this is a supported setup. Check back here and I will keep you posted.
15 Comments
Leave a Reply
You must be logged in to post a comment.
Excellent post Tazz. I am certain all your hard work and troubleshooting to make this work will come in handy in the future, so thanks in advance!
Omer
Excellent post Tazz. I am certain all your hard work and troubleshooting to make this work will come in handy in the future, so thanks in advance!
Omer
hi hi… well i’m sure there will be more challenges in the future :D nice to see you have got it to work ’cause i sold this nice concept again but now to a customer of us :D
hi hi… well i’m sure there will be more challenges in the future :D nice to see you have got it to work ’cause i sold this nice concept again but now to a customer of us :D
I always like a good challenge! Bring it on, Rene :D
I always like a good challenge! Bring it on, Rene :D
Hi Tazz ! The virtual desktops you deployed inside customer vlans, do they need to be part of the same domain as the View connection server? Is it possible to have the VMs under a workgroup or joined to the customers domain instead? Good work!
Hi Tazz ! The virtual desktops you deployed inside customer vlans, do they need to be part of the same domain as the View connection server? Is it possible to have the VMs under a workgroup or joined to the customers domain instead? Good work!
The VMs do not have to be part of the same domain as the VMware View Connection server. So it is possible to deploy the VMs in the customer domains or you can even deploy them in a workgroup.
The VMs do not have to be part of the same domain as the VMware View Connection server. So it is possible to deploy the VMs in the customer domains or you can even deploy them in a workgroup.
I am confused about the VMs not being part of the domain comment. I thought the desktop VMs had to be part of the same Domain as the CS. How are you able to deploy VM in just a workgroup? can you provide details?
J
I am confused about the VMs not being part of the domain comment. I thought the desktop VMs had to be part of the same Domain as the CS. How are you able to deploy VM in just a workgroup? can you provide details?
J
@Jay Usrr: No, the VMs do not have to be part of the same domain as the VDM/CS. We don’t deploy VMs in a workgroup. The VM are members of the various customer domains.
Note: I have tried deploying VMs in a workgroup and it works fine.
@Jay Usrr: No, the VMs do not have to be part of the same domain as the VDM/CS. We don’t deploy VMs in a workgroup. The VM are members of the various customer domains.
Note: I have tried deploying VMs in a workgroup and it works fine.
Well , the view of the passage is totally correct ,your details is really reasonable and you guy give us valuable informative post, I totally agree the standpoint of upstairs. I often surfing on this forum when I m free and I find there are so much good information we can learn in this forum!