Bowulf – Virtualization and Infrastructure Architect blog

TarryBlogging – Virtualization For Everyone: VMTN Discussion: Microsoft pulling the 90′s trick on VMware?

I’d hate to start any wars. Heck on the virtualization space we are already at war for quite some time!Join the discussion OR read the original blog that spurred this discussion.

As the original author said, Viridian will not be out until most likely . . . → Read More: TarryBlogging: Viridian vs ESX – I.E. vs. Netscape

Here was my internal response to the Gartner Virtualization Risk paper, an excerpt from Gartner’s Intro: (Gartner’s comments in italics)

“Virtualization, as with any emerging technology, will be the target of new security threats,” said Neil MacDonald, vice president and Gartner Fellow. “Many organizations mistakenly assume that their approach for securing virtual machines (VMs) will be the same as securing any OS and thus plan to apply their existing configuration guidelines, standards and tools. While this is a start, simply applying the technologies and best practices for securing physical servers won’t provide sufficient protections for VMs.”

XXX infrastructure team has consistently taken the best practice approach to applying new technologies into our environment. Our security of virtual machines is based upon our practices for securing the physical servers – namely admin granularity, patch currency, and implementation security of least privilege. Virtualization certainly represents a new layer of complexity to the technical aspects environment, but security of data on the virtual machine remains essentially the same. Unlike Gartner’s assertion, much of the existing processes and procedures already in place will maintain our existing security level.

During this process, organizations must consider these security issues in virtualized environments:

• Virtualization software, such as hypervisors, represent a new layer of privileged software that will be attacked and must be protected.

Patching the Hypervisor (vmkernel) is currently done on a routine basis, and the virtualization layer is subject to the same patch strategy recommendations, which all servers are subject. Our security department routinely evaluates that security vulnerabilities, which are released, and makes the recommendation on our risk/vulnerability assessment. The security department additionally conducts vulnerability scans on each new ESX host before being implemented into production for security vulnerabilities. This assessment has proven invaluable to discovering prior vulnerabilities, which is much more positive approach than highlighting a concern without possible mitigation.

• The loss of separation of duties for administrative tasks, which can lead to a breakdown of defense in-depth

Continue reading Gartner: Vritualization Risks and my rebuttal

I spoke on this subject during VMworld 2005:

VMware has now put a line in the proverbial sand that reliance on simply being able to virtualized is no longer enough. Take that, Xensource, and your aspirations. You must be able to do that and X. To keep pushing X will be where their future profits lay – . . . → Read More: Hypervisor (Xen and VMware) performance comparisons

Just an update on a previous post about ESX incompatibility with x3550, the solution from IBM was to install 3.0.2 or install a BIOS patch, which was not released (at that time) yet. Fortunately, it was released ahead of schedule, and the patch eliminated the aesthetic error message. We have deployed the latest BIOS on the . . . → Read More: Update on ESX on x3550

Our implementation of ESX in the past have typically taken the approach of “if it’s not broke, don’t fix it.” Consequently, I typically have not been very agressive in our patching to the various vulnerabilities and enhancements that VMware releases. Part of that had to be the difficulty any patch solution is for VMware with 16 . . . → Read More: VMware VI3 HA, or How I learned to stop fearing patching ESX Servers

Our main virtualization platform of choice has been IBM xSeries servers, specifically xSeries 3850. We have 5 remote offices that are now being deployed domain controllers and decided to use a smaller model (x3550) instead. Upon first load of the OS, we get the following error message:0:00:00:12.996 cpu0:1024)PCI: 1650: failed for 000.08.0I called VMware support, and . . . → Read More: IBM xSeries 3550 – not supported on ESX 3.0.1?