Minor confusion about the release date of Cisco’s Nexus 1000V virtual switch

Colin McNamara’s blog is usually excellent, all the more annoying that his post titled  Cisco releases Nexus 1000v  virtual switch for VMware created a lot of confusion by not distinguishing between the terms “announces” and “releases” which mean entirely different things in marketing speak …

Just for the record, Cisco’s announcement states: “The Cisco Nexus 1000V distributed virtual software switch with VN-Link capabilities supported in a VMware Infrastructure environment is expected to be generally available to customers in the first half of 2009.” Most observers agree that this means the release date will actually be June 30, 2009 at the earliest. Btw, the “V” in “1000V” is capitalized.

If you follow the discussion it is, of course, impossible to release an ESX integrated switch until VMware releases the next version of their virtual infrastructure. The current VMware version just does not have the hooks to plug in a switch that replaces the built-in vSwitch.

Except for the word “releases” in the title, Colin’s post is highly recommended reading. What I like best is his analysis of the lack of people that can do both networking and virtualization and the passing remarks about all you have to do in order to do appropriate network configurations in the virtual server world. And, most of all, the post is fun to read!

</tom>

It’s really hybrid virtualization security

Finally I have some time to write about The Four Horsemen of the Apocalypse, the BlackHat version of Chris Hoff’s work in progress by the same name.  Since I have not actually heard the talk, I am only relying on the published presentation which gives me a lot of creative freedom …

First, this is probably the best overall tour of security in virtualized environments I have seen. Obviously it is not a technical paper but rather a (very necessary) propaganda  instrument.  The “Guidelines” at the end (pages 159-175 of the version linked above) are a nice hands-on summary of  where we should go. That propaganda is necessary and confirmed on a daily basis by conversations with VMware users. It is not uncommon to operate thousands of VMs in a single LAN without any separation.

Based on my fairly large sample, it basically boils down to whether networking and security specialists are involved in setting up the virtualized environment. More frequently than not, neither specialty is on board.

What I liked best in the technical area is the classification of security approaches (on pages 78-118, my numbering):

1. No security (the dominant reality, see above)
2. External security
3. Virtual security appliances (VSAs)
4. APIs (basically what will be in VMsafe)

This is mostly a tour that clarifies what can be done, spiced with a heavy dose of VSA-skepticism. Given that I (among other things) build VSAs for a living, it is a bit surprising that I mostly agree with him: VSAs actually have a fairly limited scope – and a number of problems.

My take is that we will run hybrid environments that combine all of the above for quite a while, with (2) the most important for now, and (4) catching up (as long as VMsafe is not released there are not many API-based options). (1) is, of course, unsatisfying, but a pretty dominant reality and (2) is really only completing the picture (but the heavily touted cases such as securing VM-to-VM traffic are mostly of theoretical interest).