VMworld is clearly the largest dedicated virtualization conference, and yet from an Open Source perspective it is slightly disappointing because the VMware ecosystem naturally attracts proprietary software vendors, and also some of the more interesting activities in Open Source are through multi-vendor foundations which do not have the same marketing budgets as vendors themselves.
Nevertheless, there are a number of key Open Source players, and some interesting smaller players, represented at VMworld.
Unless you have been on vacation or hiding under a rock then you have heard the latest buzz in the industry that vSphere 4.1 has been released. There have been a lot of blog posts on the topic already including one of our own. The thing I want to hit on for this post is the fact that this release will be the last release for full version of ESX. Moving forward on any new releases of ESX will be strictly ESXi. Anyone that knows me over the years knows that I have not really been a big fan of getting rid of the full version ESX. Call me old school and the fact that I have spent a great deal of time developing the automation used in the environments that I have supported over the years and have been really happy with what I was able to accomplish via kickstart and the command line.
We all know that ESXi is the future for VMware are regards their Hypervisor strategy, however most of you are more that aware pf the issues with the current iteration (see my eariler post) . Vladan, a French based (well Reunion Island based to be exact) blogger of whom I have great respect, wrote about how ESXi does not support Serial and Parallel ports.
How is this an issue? Vladan correctly states the vast majority of SMB’s still use Parallel and Serial based devices in their environments. ESX Classic fully supports Serial and Parallel ports but ESXi does not, surprising considering that they are supposed to use the same code base. Now according to this KB article there is a workaround, but the fact remains that it is a workaround and not a true solution as the use of named pipes will require communication from a VM to the management appliance where you have to create the pipes. There are several reasons why this is an issue:
I recently spoke at the InfoSec World 2010 Summit on Virtualization and Cloud Security and also attended the main conference sitting in on many Virtualization discussions. Perhaps it was the crowd, which was roughly 30-40% auditors. Perhaps it was the timing as SourceBoston was also going on, as well as CloudExpo in NY. But I was surprised to find that people are still ‘just starting’ to think about Virtualization Security. Since I think about this subject nearly every day, this was disappointing to me at best. I found ideas around virtualization security ranging from:
- Virtualization Security is not part of an architecture/design, what do I bolt on?
- My Physical Security will work
- Virtual Environments NEED More security than physical environments
- There are no new threats, so why have something more
- Security is a hindrance
Well the worse kept secret in virtualization is now finally out in the open, have a read of VMware ESX to ESXi Upgrade Center:Planning your Upgrade to the next-generation hypervisor architecture where they state that “In the future, the superior architecture of ESXi will be the exclusive focus of VMware’s development efforts. This means that not only will the ESXi hypervisor supersede the classic ESX hypervisor in a new version of vSphere; what the time scale is, is currently unknown however it is most likely to be vSphere 5 or whatever they decide to call the next major release. What is more interesting in statement is that VMware expects their customers to upgrade their existing installations of vSphere based on the ESX hypervisor to the new ESXi hypervisor.
I was posed with a question today, “I’m looking for some info on account & password management for consultants that visit a lot of customers where they have to do admin stuff.” with a secondary question of “how to manage the account if a constultant leaves?” This was specific to the VMware vSphere but would apply to any hypervisor.
There are two issues:
- How to control who can access the administrative functions within their own datacenter and how to access administrative functions on remote systems spread all over the world.