VMWorld 2008: “Introducing Cisco’s Virtual Switch for VMware ESX”…
Update below.
It's the night before VMworld 2008 and the Technology
Exchange/Partner day begins and I'm pawing through the stuff in my bag,
separating the "keep it" from the "toss it" schwag.
There's an innocuous little flyer stuffed in the bag on Cisco
letterhead titled "Introducing Cisco's Virtual Switch for VMware ESX."
Fantastic. Let's call it the 'cSwitch' 😉
A year and a month ago in August of 2007, I blogged about this very thing in a post titled: "VMware to Open Development of ESX Virtual Switches to Third Parties…Any Guess Who's First?" based on a hint from virtualization.info.
Given
that VMworld 2007 came and went without this announcement, I'm very
excited that we're actually going to get a look at what Cisco will
offer; I think this is huge news and ultimately offers some profound
game-changing (for good and bad) implications on the network and
security fronts.
I have dozens of questions like: I wonder how
much of the Nexus (7000 series)/NX-OS code cross-pollinates over (if
any) to this solution and if we'll see capabilities such as
STP/PVST+/Private VLANs, HSRP, Multicast, etc. make their way into
Cisco's vSwitch and how this virtual switch with integrate/interoperate
with the vkernel.
Further, as Ed Haletky and I unofficially bet
over drinks this evening, I wonder if it will be a direct replacement
for VMware's at-boot loadable module or it will co-exist? I bet the
former. 😉
In addition to the "cSwitch," there are a couple of
sessions I am very, very interested in attending given my exposure to
VFrame and some Cisco engineers/architects at last year's show:
Simplify VMotion with Virtual Machine–Aware Network and Storage Services
See how network and storage services can be linked to a virtual machine so they move with VMotion events.
ESX Server in a Unified Fabric Environment
See how ESX Server works in a unified fabric environment with ESX 3.5
U2, Emulex Converged Network Adaptors, and the Cisco Nexus 5000.
VFrame: Enriching ESX Deployment with End-to-End Orchestration
Cisco’s VFrame DC 1.2 provides an easy-to-use template-based
provisioning approach for rapid, repeatable, and compliant provisioning
of ESX Servers. Through a rich set of networking and storage
orchestration capabilities, it reduces the time required to bring up
ESX clusters while providing operational scalability to manage large
clusters effectively.
See the second topic above? Remember when I mentioned in prior posts about virtualizing applications directly within the Nexus?
Should be a very interesting couple of days.
/Hoff
Update:
So there was no direct news/mention specifically of Cisco today in any
of the distributed virtual networking (DVN) sessions — there's a lot
of messaging collisions because the re-branded 'v-everything' strategy
has things being renamed. Hopefully we'll see/hear more from Cisco
tomorrow.
Many
of the underlying functions that will enable 3rd party virtual switches
as well as any network interface to the vkernel via API were discussed today
under the capabilities described by vNetwork (this includes the vNetwork Appliance API's and what you've known as VMsafe.) You can see more about vNetwork here in this post.
All
I can say is that I got a lot of my suspicions confirmed, questions
answered and conclusions affirmed in today's sessions. Some good, some
bad. It's going to be a bumpy ride, kids.
The Four Horsemen live! 😉
Time to get crackin' on CISCO IOS vulnerabilities. Adds a whole new level to MITM eh?
So based on what you said…
"I have dozens of questions like: I wonder how much of the Nexus (7000 series)/IOS-XE code cross-pollinates over (if any) to this solution and if we'll see capabilities such as STP/PVST+/Private VLANs, HSRP, Multicast, etc. make their way into Cisco's vSwitch."
…I would assume that Cisco would *have* to support those features at a bare minimum. Nothing in those capabilities is really anything new or outrageous and is standard feature set on the most basic of Cisco switches. The more interesting thing may be if these switches will be VRF aware, how they will handle routing protocols (if at all), RSPAN/VSPAN/Local SPAN, and if there will be any modular feature sets built in that may be able to replicate dedicated module functionality (i.e. FWSM, IDSM, etc..).
I guess I'm not excited about "the basics" because I think that Cisco has already realized that this is a big market for them and they have to put something out with a good feature set. The one area Cisco is still decent in is switching and routing, so I'd expect a good deal of options available even early on…
I don't think you're going to see a lot from the 7k series, because the majority of the uniqueness in that platform revolves around VDCs. And, well, it's already a virtual switch, so I would expect them to have some sort of management framework for multiple vSwitch instances within a chassis already. This would allow them to have, quite possibly, different feature sets that are specific to certain uses much more easily — rather than virtualize an already virtualized component.
And now we get back to the resource utilization problem I've mentioned here before. I'm curious to see how they'll be dealing with that. I would have to forecast you'll see Cisco-on-a-board sometime soon that you can just snap in to the platform and get some, much needed, hardware assist without impacting the platform as a whole.
Just my $0.02.
–windexh8er
@windexh8er:
So the Nexus 1000V is a full implementation of an NX-OS switch, so it has the same feature set at the N5K and the N7k, including advanced features such as Netflow, private VLANs, ERSPAN, etc.
From a management perspective, the N1Kv looks and acts like any other Nexus switch. In fact, the architecture for the switch resembles a virtual modular switch, where each server running an N1Kv looks like a linecard.
Part of the announcement is on Tuesday was the point that we (CSCO, VMW) have joint created a proposal for a protocol for Network Interface Virtualization and presented it to the IEEE this week for ratification as an open standard. This protocol will allow VN-Link to be implemented in hardware.
Omar Sultan
Cisco