Category: virtualization

One of my readers left a comment on my “optimize your data center by virtualizing the servers” blog post saying (approximately):

Seems like LinkedIn did it without virtualization :) Can enterprises achieve this to some extent?

Assuming you want to replace physical servers with one or two CPU cores and 4GB of memory with modern servers having dozens of cores and hundreds of GB of memory the short answer is: not for a long time.

Mr. A. Anonymous, frequent contributor to my blog posts left this bit of wisdom comment on the VMware NSX Update blog post:

I don't understand the statement that "whole NSX domain remains a single failure domain" because the 3 NSX controllers are deployed in the site with primary NSX manager.

I admit I was a bit imprecise (wasn’t the first time), but is it really that hard to ask oneself “what happens if the DCI link fails?”

A while ago I guestimated that most private clouds don’t have more than a few thousand VMs, and that they don’t need more bandwidth than what two ToR switches could provide.

Last autumn Iwan Rahabok published a blog post describing the compute- and storage parts of it, and I had a presentation describing the networking aspects of high-density consolidation. However…

One of the engineers watching the vSphere 6 Networking Deep Dive found it particularly useful:

There were pearls of knowledge in there which expanded my understanding of ESX and gave me more than a few "aha!" moments […] The course is worth the money and time for sections "uplink redundancy & load balancing" and "VLAN based virtual networks" alone.

Not convinced? Check out other reviews and survey results.

A few months ago VMware launched NSX version 6.2, and I asked my friend Anthony Burke to tell us more about the new features. Not surprisingly, we quickly started talking about troubleshooting, routing problems, and finished with route-health-injection done with a Python script. The end result: Episode 50 of Software Gone Wild. Enjoy!

It all started with a tweet by Stephane Clavel:

@ioshints @BradHedlund I'm puzzled NSX dFW does not track connections seq #. Still true? To me this is std fw feature.

— stephaneclavel (@stephaneclavel) January 31, 2016

Trying to fit my response into the huge Twitter reply field I wrote “Tracking Seq# on FW should be mostly irrelevant with modern TCP stacks” and when Gal Sagie asked for more elaboration, I decided it’s time to write a blog post.

Harry Taluja asked an interesting question in his comment to one of my virtualization blog posts:

If vShield API is no longer supported, how does a small install (6-8 ESXi hosts) take care of east/west IPS without investing in NSX?

Short answer: It depends, but it probably won’t be cheap ;) Now for the details…

A year and a half ago, Docker networking couldn’t span multiple hosts and used NAT with port mapping to expose container-based services to the outside world.

Docker is the hottest Linux container solution these days. Want to know more about it? Matt Oswalt is running Introduction to Docker webinar in a few days.

In August 2014 a small startup decided to change all that. Docker bought them before they managed to get public, and the rest is history.

One of my readers sent me this question:

I'm researching NFV/SDN and wonder if the software L2 switches support spanning tree.

TL&DR: Some do, some don’t.

I love listening to the Datanauts podcast (Ethan and Chris are fantastic hosts), starting from the very first episode (hyper-converged infrastructure) in which Chris made a very valid comment along the lines of “with the hyper-converged infrastructure it’s possible to get so many things done without knowing too much about any individual thing…” and I immediately thought “… and what happens when it fails?”

Last year I claimed that you don’t need more than two switches in your data center (I’ll run a presentation on the same topic in a few days), but focused exclusively on the networking side of the equation.

Iwan Rahabok recently published a great blog post describing the compute- and storage parts of it. His conclusion: 1000 VM per rack is perfectly realistic.

I had fun times participating in a discussion focused on whether it makes sense to deploy OTV+LISP in a new data center deployment. Someone quickly pointed out the elephant in the room:

How many LISP VM mobility installs has anyone on this list been involved with or heard of being successfully deployed? How many VM mobility installs in general, where the VMs go at least 1,000 miles? I'm curious as to what the success rate for that stuff is.

I think we got one semi-qualifying response, so I made it even simpler ;)

During my recent SDN workshops I encountered several networking engineers who use Nexus 1000V in their data center environment, and some of them claimed their organization decided to do so to ensure the separation of responsibilities between networking and virtualization teams.

There are many good reasons one would use Nexus 1000V, but the one above is definitely not one of them.

When I wrote my stretched VSAN post, I thought VSAN uses asynchronous replication across WAN. Duncan Epping quickly pointed out that it uses synchronous replication, and I fixed the blog post.

The “What about latency?” question immediately arose somewhere in my subconscious, but before I could add that thought to the blog post, Anders Henke wrote a lengthy comment that totally captured what I was thinking, so I’m including it in its entirety:

Pirmin Sidler read the stretched VSAN blog posts by Duncan Epping (intro, HA/DRS considerations, demo) and asked me what I think about stretched VSAN considering my opinions on long-distance vMotion.

TL&DR answer: it makes way more sense than long-distance vMotion. However…