Following my last post about administration and monitoring tasks in VMware 5, I will talk about another promising feature of VMware vSphere 5.x: supporting NetFlow. NetFlow is a network protocol developed by Cisco for collecting IP traffic information. NetFlow has become an industry standard for traffic monitoring.
As I wrote earlier, cloud/network engineers would like to have the same capabilities in virtualization as they have in physical networks and nowadays NetFlow is turning out to be the new trend in producing networking devices such as switches. In the same way switches support NetFlow, VMware implemented NetFlow that can be enabled on vSwitches, specifically very useful in Distributed switches. Good to mention that from version 5.1 VMware also supports newer version of NetFlow which is IPFIX. You can find more information about NetFlow by itself on the internet.
Configuring NetFlow in VMware vSphere is a 2 step process:
- Configure NetFlow properties on the dvSwitch.
– Port is a UDP port which NetFlow collector will listen on. In NFDUMP, it is 23456! by default.
– Of course, IP session between dvSwitch and NetFlow collector should be established in a proper way. I mean dvSwitch should see NetFlow collector.
- Enable NetFlow on the specific dvPort group.
That’s it. In the next post, I will show how you can use a free, simple NetFlow Analyzer (nfdump, nfsen) to gather and display information about IP traffic flows in your dvSwitch.
As a network or cloud administrator in VMware environment, we would like to have the same capabilities we’ve got in a physical network. One of the most important tasks is network traffic monitoring and inspection control. Let’s say you want to install a network Intrusion Detection System (like SNORT) to monitor the traffic of a specific Virtual Data Center in vCloud environment that is translated to monitoring a specific VLAN or port group in VMware vSphere. Fortunately, VMware 5.x provides these features but apparently implementing these features is beyond VMware vCloud Director operations and it’s part of infrastructure administration tasks introduced in vSphere 5.x.
Since normally there is a port group in Distributed Virtual Switch defined by vCloud Director for each virtual data center, let’s talk about port groups in VDS. You may have noticed that when you want to create a port group in a distributed switch, you can define some security policy and one of the policies is enabling ‘Promiscuous Mode’. This is exactly equivalent to enabling promiscuous mode in a physical switch. So, as shown in the following picture, a port group can be edited to enable this mode (in vSphere Web client).
The only concern is that promiscuous mode should be defined on a port group or the whole distributed switch and not on a particular port. Doing this will cause all the traffic to be forwarded to all of the VM’s in that port group! and apparently it’s a security risk because we would like to forward the traffic to only one specific VM (port) which is our IDS. A work-around here would be to define a new port group with the same VLAN ID of the port group/VLAN we would like to monitor with the exact same configuration, then enable promiscuous mode for this newly defined port group and place the IDS VM in this port group. Because VLAN ID is the same, only IDS VM would see all the traffic. That’s an easy trick! BUT I don’t know how this trick works in some vCloud port groups that use VCDNI-backed port groups instead of VLAN-backed network pools because as I understood, VCDNI is kind of encapsulation introduced by vCloud Director and I’m not sure if a port group that is created inside vCenter can decapsulate packets. I didn’t find enough information, so I will test this out and report it in this blog.
Another approach is to use Port Mirroring feature of a VDS. Using this method it’s possible to specify source ports which need to be monitored and destination port/ports where IDS is located.
This solution is explained in detail in the following link:
vSphere 5.1 – VDS Feature Enhancements – Port Mirroring
Migrating and relocating VMs is a great feature in Virtualized environments. You can do migration and perform your maintenance without disrupting any service. Migration in VMware is easy by utilizing vMotion in vCenter. You right click on VM, then choose Migrate and follow the instructions. But how we can relocate (change datastore or storage vMotion) a VM in vCloud Director?
Actually I was expecting the procedure in vCloud Director to be similar to vCenter, but when I right-clicked on the VM, I couldn’t find a ‘Migrate’ option or something like that. And apparently it’s not a good practice to migrate a VM which is controlled by vCloud Director through vCenter. But fortunately storage vMotion is possible in vCloud Director if you have separate Storage Profiles. To do this kind of relocation, right-click on the VM, then choose ‘Properties’; in ‘General’ tab you will find a pulldown menu for changing Storage Profile. Simply change Storage Profile to the desired one and bingo! Storage will be changed. You can even see the progress of relocation in vCenter.
- As mentioned, changing datastore is possible if proper storage profiles are defined in the environment. That being said, it’s not possible to relocate to an individual, specific datastore. Actually, storage profile is another abstract layer over storage infrastructure that is being used by vCloud Director. To be honest, I didn’t have deeply realized what’s the main purpose of introducing storage profile and storage capability yet and why it doesn’t use datastore cluster instead. By the way, keep in mind that you need to create separate storage profiles if you have separate storages and you want more flexibility in vCloud. To get more information, look at this link: Using Storage Profiles with vCloud Director.
- I couldn’t find much resources on the effects of migrating a VM from one host to another in vCloud Director environment; it is possible to perform this in vCenter and I did it in some cases with no issues. I suppose vCloud Director is working on higher level and will be notified of the changes.
I’ve got some design considerations about creating Volumes in storage which supposed to be used by virtualization infrastructure (VMware 5.1) as datastore; I ended up reading this great article by Michael Webster which saved my day and I would like to share:
The Case for Larger Than 2TB Virtual Disks and The Gotcha with VMFS
Overall, it seems that VMware vSphere 5.5 has good advantages and improvements over 5.1.
Since VMware vCenter uses ports 80, 443 to provide access to management console (for both vSphere Client and Web Console), it’s important to secure these ports. Having said that, it can be limiting access to specific IP addresses in your internal network. If there is no firewall between your internal network and Cloud infrastructure, at least configure Firewall in Windows machine (if vCenter is installed on Windows) to restrict access.
Also, for a complete list of tasks to harden vCenter Security, you can see Security Advisories, Guides document from VMware.
Remember to change default value of “Highest supported hardware version” from 7 to 9 when you create a Provider vDC in VMware vCloud Director 5 or you will face some issues later on when you want to import VM’s from vCenter to your Catalogs and will get this error message:
“The selected vdc does not support required virtual hardware version”
The interesting point is that VM’s in vCenter are created compatible to Hardware Version 8 by default! In fact, there are some inconsistencies between vCenter, vSphere and vCloud Director; it is just one of them.