Private VLANs in vSphere

PVLANs is one of those features that everyone should have in their mental “toolbox”.  We were looking for a way to fence off portions of a network with minimal effort, but they didn’t really require a whole separate subnet. For example, maybe to enhance security, or for pre-production VMs.  (Obviously, this is assuming properly configured switches)  For those that are unfamiliar with PVLANs, check out VMware’s KB on the subject. Essentially, it allows you to further segment a VLAN using different groups (promiscuous, isolated, community)

The promiscuous group can talk to all other groups.  The community group can talk among itself and the promiscuous group, and isolated can only talk with promiscuous (not even other members in the isolated group!)

Traditionally, if I had two servers in the the same subnet and same vlan, I may have had to create firewall rules to stop traffic or some other means.  Maybe reconfigure the network or addressing.  Maybe not such a big deal, but what if I added 10 more servers.  50 more servers?  Rules and firewall configuration could get kinda hairy.

Using PVLANs in vSphere, I would create the PVLAN, PVLAN groups, and then create the port group associated with the PVLAN groups.  Then, assign the VM to the required port group. In our case, infrastructure servers like the Domain controller were set to the promiscuous group.  But, we wanted to restrict traffic between all RDS servers, which were assigned to the Isolated group.

I will note that the behavior of PVLANs can be achieved through other means, depending on what exactly your trying to accomplish.  Also, they are not a replacement for firewall rules in most cases, you will still want to restrict traffic as needed to those VMs in the promiscuous group.  However, PVLANs seem to be a great broad solution and should be considered to augment such designs.



james gonzales / March 29, 2016 / Networking, Virtualization, vmware / 0 Comments

Recover VM’s from a permanently down XenServer host.


We recently had a XenServer node crash to the point it was not possible to recover.

The VM’s that had been operating on the host were no longer visible in XenCenter and had seemingly disappeared.

The first you need to do is locate the UUID of the down host with




Then display a list of all the VM’s on the failed host with

This will output all the VM’s on that host and indicate that they are in a “running” state.

We need to reset the powerstate of each VM.

Once you run this command you will notice the VM appear in XenCenter.  You will more than likely not be able to start the VM due to the VDI being in use by the downed host.

you’ll need to reset the locks on the VDI, this can be done by forgetting the UUID of the VDI and reattaching it to the VM.

One way to do this is to run


This will gernate an error but more importanly it will also tell you the UUID of the VDI that is in use.

Then you need to “forget” the VDI


this will cause the VM to “lose” the disk, rescan the SR and you’ll see the disk without a VM.

Go to the storage tab of the VM and reattach the VDI and then restart the VM either with XenCenter or


note: if the VM has more than one disk youll need to repeat the process of running


and each time it will show you the VDI causing the issue.


There is a way to reset the VDI’s on a given SR as the above can be time consuming with a large number of virtual machines but this post will not cover that method.




casey jones / March 7, 2016 / Citrix, Virtualization, XenServer / 0 Comments