blog.virtualtacit.com

Root Down in a 2009 World

Archive for the ‘vmware’ tag

My Hypervisor is better than yours…and here’s why

without comments

So Laverick beat me to the punch on this one as I was preparing a post on this exact blog, but any who, I thought I would comment on it….

Straight from the horses mouth is an interesting post from the blog fancied, VMware: Virtual Reality that explains some of the major architectural differences between Hyper-V, Xen and ESX. A bit marketing tainted, the post describes such items as the reasoning behind the “Direct Driver” (ESX) architecture as opposed to the “Indirect Driver” (Xen, Hyper-V) architecture, hypervisor sizing, memory management and overcommitment, and shared storage. There really is nothing like a few netperf graphs, an “Uptime” taunt, and the smell of gun powder in the air to kick off the 4th!!!

Written by Joe Kelly

July 5th, 2008 at 3:37 am

Posted in vmware

Tagged with

VMware gets serious-DMZ Virtualization Best Practices

without comments

For any engineer that has deployed virtualized solutions, DMZ configurations are par for the course. Customers live and die by their presence and availability  on the web and you as a engineer should be versed in proper DMZ deployments. Not only to, most importantly, protect the customers internal data but to keep you and your companies name in good standing. As part of this new initiative toward security awareness and preventative maintenance, VMware has published a quick read on DMZ Virtualization with VMware Infrastructure, download here. What follows is a brief synopsis of the three most typical DMZ deployments in a virtualized environment:

  • Partially Collapsed DMZ with Separate Physical Trust Zones
    • Zone separation achieved through independent clusters
    • Firewalls, IDS, IPS’s, etc. are physical devices requiring no change
    • All servers within each zone are virtual servers
    • Most common approach I have seen as it is the easiest. Network isolation is completely physical removing the need for VLANs.
    • Typically the approach that most larger organizations use, loose the benefit of resource consolidation, reduced power and cooling and all the other salubrious ends to virtualization
  • Partially Collapsed DMZ with Virtual Separation of Trust Zones
    • This approach is a hybrid of sorts, layered between the SPTZ deployment and the DMZ in a box.
    • The virtual software is now a participant in the separation of security zones. Virtual switches corral which virtual servers can see which zones. The physical network devices are gatekeepers, controlling the security and communications between each zone.
    • Complexity level rises in such configurations although there is a greater balance between cost and resource utilization
  • Fully Collapsed DMZ
    • Full DMZ in a box or host that is. Complete virtualization of all entities involved (ie.vServers, vSecurity appliances, vFirewalls, etc.)
    • Certainly the most complex of all configurations, user appropriation a must
    • Again full utilization of resources and low cost is a huge driver for this approach
    • Full auditing suggested across firewall and switches to maintain VM availability, especially in tandem with the advanced features of your VI (DRS, VMotion, etc)

To conclude, choosing the most apt DMZ design should ideally take into consideration the  number of physical NICs available, the customers internal security practices, as well as their tolerence for complexity. With this information in your back pocket and the developement of such programs as VMsafe , together we can snuff the negativity built around virtualization and security.

In addition, make sure to check out the following references as there is a lot of useful information geared toward securing virtual infrastructure.

Written by Joe Kelly

June 30th, 2008 at 7:33 pm

Posted in vmware

Tagged with

64-Bit VI Client Support in Update 1

without comments

For all of you individuals out there that were circumventing solutions around running the VI client from a 64-Bit OS, VMware finally decided to add support for this in Update 1. In short you will need to install .NET 2.0 (x64) prior to the installation of the client. Here is the link for your reference.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1004093

Written by Joe Kelly

May 12th, 2008 at 6:51 pm

Posted in vmware

Tagged with