Networking

• For all the writing and thinking I’ve done on VXLAN (here, here, and here), someone (thanks Ed!) mentioned something to me recently that I hadn’t even considered. (It’s so simple I’m embarrassed that I overlooked it.) VXLAN uses UDP for its encapsulation. What about dropped packets, lack of sequencing, etc., that is possible with UDP? What impact is that going to have on the “inner protocol” that’s wrapped inside the VXLAN UDP packets? Or is this not an issue in modern networks any longer?
• Since Ivan thinks we do need to worry about spaghetti and horseshoes, I’m curious to know if he thinks we need to worry about UDP as the transport for VXLAN.
• Jake Howering of Cisco (with whom I’ve worked on a few occasions) posted a couple of good articles on the Cisco Data Center and Cloud blog. Jake focuses on DCI (data center interconnect), so his articles naturally reflect that focus. The first article discusses the use of LISP for ingress path optimization in VM mobility scenarios. Ingress path optimization is only half of the solution, though; Jake discusses the other half in the second article, which covers egress path optimization with FHRP filtering, something I discussed in my recent VXLAN/OTV article.
• It looks like you can’t create a vPC (virtual port channel) between a Nexus 55xx and a Nexus 50×0 switch.
• Kyle Mestery speculates a bit here about integrating VXLAN in OpenStack Quantum.

Servers/Applications/Operating Systems

• I’ll put this under the “Servers” category even though it’s storage-related: In this post, Ryan Hughes explains how to use the UCSM CLI to do some cool—and useful—boot from SAN troubleshooting.
• Purely by accident, I stumbled across this humorously-titled series regarding Oracle on Fibre Channel. It turns out the author works for EMC, although I didn’t know that ahead of time. In any case, if you’re interested in finding out how manly men deploy Oracle, check out the series titled “Manly Men Only Deploy Oracle with Fibre Channel” (parts 1, 2, 3, 4, 5, 6, 7, and 8).

Storage

• Clint Kitson recently published a guide on setting up the FC zoning for WAN communications on a VPLEX Metro cluster. This article is a good complement to my own MDS zoning articles (creating MDS zones, managing MDS zones, using device aliases) and shows some practical examples of those commands in action.
• Simon Seagrave points out a firmware update for Iomega IX2 and IX4 storage devices that fixes problems with Time Machine under Mac OS X 10.7 “Lion”. Thanks Simon!
• This post by Hans De Leenheer was written in July of last year, but it only came to my attention in late November after I met Hans in Vienna during my “round the world” trip. (Great guy, by the way.) He asked me to respond to his criticism of EMC’s “mega-launch” in early 2011. I wish I could say Hans is way off, but I personally agree that the hyperbole was a bit much. I do have to disagree a bit with his comment about no new products; while EMC didn’t introduce all new hardware for some lines (like the VMAX), they did introduce new array software (like Enginuity 5875 for the VMAX). Does that count as a “new product”? I guess the answer to that depends on whether you work in marketing. At least it’s good to hear that Hans feels EMC is, in his words, “a solid company making solid storage solutions”. Perhaps EMC should focus more on that…
• Erik Smith has written a very detailed post on FC/FCoE hard zoning versus soft zoning. It’s an excellent post, and well worth the time if you aren’t already an FC/FCoE expert. By the way, if you haven’t yet subscribed to Erik’s RSS feed, I highly recommend it. He puts out some great stuff.
• David Robertson wrote up the steps for creating a Linux-based SMC/SPA server, in the event you use EMC Symmetrix in your environment.

Virtualization

• If you haven’t read this vSphere 5 APD/PDL post by Cormac Hogan, go read it now. Seriously.
• Several bloggers weighed in on the release of PowerCLI 5.0.1, which adds support for automating VMware vCloud Director. You can get more information from Julian Wood or Luc Dekens.
• Forbes Guthrie, lead author on VMware vSphere Design (for which I was a co-author), has released a vSphere 5 version of his vReference card.
• Chris Wahl posted an article on managing user assignments in VMware View dedicated pools. Watch out for Mr. Fancy Pants, though…
• If you are experiencing time-out errors with vSphere HA waiting for cluster election, see this post by Duncan Epping for a fix.
• Need to convert from vCloud linked clones? Chris Colotti has a solution that might work for you.
• Rick Vanover indicates that the next release of Hyper-V will support NPIV. I wonder if Microsoft’s implementation of NPIV will be as…um, good…as vSphere’s implementation. Let’s hope that Microsoft does a better job with NPIV. Personally I think NPIV has potential in a virtualized environment, but the current VMware implementation is crippled at best.
• Scott Sauer gives us a good write-up on Elastic Memory for Java (EM4J). I think EM4J is an important part of expanding virtualization’s footprint by allowing it to more efficiently handle Java workloads.
• Using vCenter Operations? You might be interested in this tool created by Matt Cowger called the vCenter Operations Data Extraction Tool.
• Gabrie van Zanten (aka @gabvirtualworld) points out an interesting interaction between licensing and DRS rules.
• Here are some potential vCloud Director design guidelines.
• Frank Denneman posted a discussion on the use of multi-extent datastores with Storage DRS (SDRS). His conclusion is that the introduction of SDRS in vSphere 5 greatly alleviates the need for multi-extent datastores, a conclusion with which I (generally) agree.
• This VMware KB article has a collection of the firewall-related commands in ESXi 5.0; this is a useful reference in my opinion.

Here are a few other virtualization-related links that I also thought you might find interesting or useful:

Are operational considerations overlooked in virtualization?
VMware KB – Detaching a datastore or storage device from multiple ESXi 5.0 hosts
What happened to vShield in vSphere 5?
Linux VMware Tools Install Changes to Upstart
VMware KB – Disabling VAAI Thin Provisioning Block Space Reclamation (UNMAP) in ESXi 5.0

Cloud Computing

• You’ll note that I didn’t lump cloud computing under virtualization, since I think that there’s more to “cloud” than virtualization (although I would grant that virtualization is a big part of it). So much more, in fact, that people are referring to cloud computing as complex. (Gasp!) But this post puts cloud complexity in perspective. If you are merely a consumer of services, then cloud is simple; if, however, you are a provider of services, then cloud is more complex. Good article.

That’s it for this time around. If you have any comments or thoughts on anything shared here, feel free to speak up in the comments.

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

Technology Short Take #20

• Technology Short Take #15
• Technology Short Take #14
• Technology Short Take #19
• FCoE through a Nexus to a MDS-Attached Storage Array
• VIR250: Advanced Storage Connectivity for VMs

One of these topics was virtual machine mobility. Here’s what Stephen wrote under the heading “How Do You Handle Virtual Machine Mobility?”:

As I described recently, virtual machine mobility is a major technical challenge for existing networks. The VMware proposal, the VXLAN, seems to be gaining traction right now. But this is only a solution for data networking. How will FCoE SANs handle virtual machine mobility? This remains unresolved as far as I can tell, though Ethernet switch vendors have come up with their own answers. Brocade demonstrated just such a solution at Networking Field Day 2, and I know that others have answers as well. But will there be an interoperable industry solution?

My response to Stephen’s question is pretty simple: VM mobility isn’t a problem for FCoE. VM mobility is a problem for all storage, regardless of protocol.

In my view, tying VM mobility to FCoE is simply buzzword hype. Let’s look at this from a technical perspective—what is so different about FCoE compared to FC, iSCSI, or NFS with regard to VM mobility? Nothing! Regardless of storage protocol, when you move a VM from one data center to another data center, the VM’s storage is still going to sit back in the original data center. The protocol whereby we access that data doesn’t change that fact.

Yes, you can route the IP-based protocols (iSCSI and NFS), which might give you some additional flexibility. But the migrated VM’s storage is still going to sit in the original data center—the only thing you’ve accomplished is introduced some additional latency by adding routers into the mix.

As you can see, VM mobility and storage isn’t an FCoE problem—it’s a storage problem, plain and simple. Protocols can’t fix it. What’s needed to fix it is a fundamental shift in how storage is designed. We need distributed file systems (not just clustered file systems), distributed caching algorithms, greater integration between the block storage and the distributed file systems, greater hypervisor awareness of the underlying storage topology, and more efficient data movement mechanisms. Until then, we can rage all we want about how this protocol or that protocol doesn’t address VM mobility, but we’re simply missing the mark.

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

What Does FCoE Have To Do With VM Mobility?

• Correction: There Might be an End-to-End FCoE Solution
• No Such Thing as an End-to-End FCoE Solution
• Continuing the FCoE Discussion
• Technology Short Take #14
• FCoE versus MR-IOV…huh?

Here’s the lowdown: there’s an issue with VSI Storage Viewer 5.1 that prevents it from properly upgrading previous versions of VSI. After an upgrade to Storage Viewer 5.1, the user may encounter an error like “Unable to load DLL ‘SEWrapper.dll’: The specified module could not be found” (or similar).

The problem isn’t in SEWrapper.dll, which is working properly and is, in fact, installed on the system. The problem is in the Microsoft Visual C++ 2010 Redistributable Package (x86) isn’t installed, and that’s a pre-requisite for the SEWrapper.dll library.

There are two workarounds for this issue:

1. Remove VSI Storage Viewer 5.1 and re-install it from scratch. This will cause the Visual C++ redistributables to get installed correctly, fixing the problem. Note: If you have older VSI features installed—like Storage Pool Management 5.0 or Path Management 5.0—reinstall those after Storage Viewer 5.1 is installed.

2. Download and install the Microsoft Visual C++ 2010 Redistributable Package (x86) separately. You should be able to download that here.

This will be in the Release Notes very soon (if not already), but I wanted to highlight the problem—and the fixes—here just in case.

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

VSI 5.1 Issue and Fixes

• Virtual Storage Integrator for Hyper-V
• VMware ESX 3.5 Update 3 is Available
• EMC Unified Storage Plugin Version 2 Now Available
• The Return of Virtualization Short Takes
• Updating Kubuntu to KDE 3.5

Networking

• While configuration limits aren’t the most exciting reading, they are important from time to time. Here’s some configuration limits for the UCS 6100 and 6200 series.
• Understanding the differences—both positive and negative—between the various approaches to solving a particular challenge is a key skill. That’s why I like this article on HP Flex-10 versus NIOC for VDI. The author (Dwayne) weighs the pros and cons of both approaches in helping to shape network traffic for VDI deployments using 10Gb Ethernet.
• It would appear that my recent VXLAN and OTV connectivity posts (incorrect VXLAN post here, corrected VXLAN post here, and OTV/VXLAN post here) sparked a discussion about whether we really need to concern ourselves with traffic trombones. On one side we have Brad Hedlund speculating that the network should be treated like a large virtual I/O fabric; on the other side we have Greg Ferro countering that we do need to be concerned about the topology of the network. I can see both sides of the argument, but at this stage of the game, I’m inclined to agree more with Greg. In the future (it’s unclear how far in the future) I think that Brad’s points will be more valid, but not right now.
• This post by Ivan Pepelnjak on VXLAN, IP multicast, OpenFlow, and control planes highlights some of the current limitations with VXLAN and thus reinforces why I think that Brad’s arguments are a bit ahead of their time.
• A few folks had some write-ups on Embrane Heleos: Greg Ferro, Jason Edelman, Brad Hedlund, Brad Casemore, and Ivan Pepelnjak. My question (and this is spurred in part by some comments by Brad Casemore): is this another Cisco spin-in move?

Servers/Operating Systems/Applications

• Want to play around with Hadoop/MapReduce? This quick tutorial might be useful in getting you started.
• This two-part series on Hadoop (part 1 and part 2) might also help you understand the value of Hadoop and where it fits into your overall technology profile.
• Continuing with Hadoop, this post by Brad Hedlund on understanding Hadoop clusters and the network gives a great overview of Hadoop and highlights some of the networking concerns/considerations.
• I mentioned that one of my 2012 projects is learning Perl, and here are three “beginner’s introduction” articles that I’ve found useful so far (Part 1, Part 2, and Part 3).
• Fellow vSpecialist Clint Kitson recently started blogging, and here’s a recent post on a function he wrote for PowerShell that brings some color-coding feedback into the environment.
• Running Mac OS X 10.7 Lion on your Mac? Then this article on setting up dual Time Machine backup destinations might be useful to you. (As an aside, I’ll add an extra plug for ControlPlane—it’s a very handy little tool that I also use).

Storage

• Are you a networking geek, but haven’t had the chance to do much with Fibre Channel? This guide to Fibre Channel switching basics for network engineers might be handy to get you started.
• Check out this post for a heads-up regarding soft media errors with SSDs and FAST Cache on EMC arrays (thanks to Chad Sakac for the link).

Virtualization

• I’m not sure how often this actually comes up, but Ben Armstrong shows here how to use “built in” applications in Windows XP mode under Windows 7. Ben also has a write-up on how to convert to a fixed virtual hard disk “the hard way”.
• Duncan revisits vSphere HA isolation response with IP storage in this recent post, pointing out a potential issue that can occur when both the IP-based storage link and the management link are lost. From what I gather from both the article and the comments, it sounds like this isn’t limited to only when the isolation response is set to “Leave Powered On.”
• If you, like me, will be expanding beyond VMware in 2012, then this open source cloud and virtualization terminology post will be useful to you. As I’ve mentioned before, one of the most important steps in learning new technologies is learning the vocabulary. (Oh, and it might be worth it to just subscribe to this site. It looks to have an interesting mix of content coming.)
• Seen the VMware Technical Publications YouTube channel?
• Here’s a good post on using vSphere Auto Deploy with Cisco UCS.
• Alan Renouf has posted a great PowerCLI script that helps automate the start-up of your virtual environment. This is a handy tool that should be in the toolbox of any administrator with a virtual vCenter instance in their environment.
• Fellow vSpecialist and VCDX Matt Cowger has a good write-up on installing the vCenter Operations Symmetrix Collector plugin.
• Kendrick Coleman has a good discussion of vCloud Director provider vDC strategies. His discussion is partially specific to Vblock, but some of the information would apply to any environment.
• Frank Denneman has a good post on the recommendation to use similar types of disks in a datastore cluster.
• Does Cisco regret not buying VMware? Brad Casemore seems to think so.
• I think I might have referenced these before, but these Linked Clone posts on the VMware vSphere blog are a good read (part 1 and part 2).
• Tony Bourke is depressed at the current state of statelessness. I can’t say that I disagree.
• Massimo has a good write-up on vCloud Director, custom portals, and backend integrations in service provider environments.

And that it’s for this time around; as always, I hope you’ve found something useful here. Courteous comments are always welcome; feel free to speak up below.

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

Technology Short Take #19

• Technology Short Take #15
• Technology Short Take #12: Networking Edition
• Technology Short Take #14
• Technology Short Take #10
• Technology Short Take #17

Here are some of my 2012 projects (some of these I’ve already tweeted about):

1. I’m going to learn to script in Perl. Many people have asked why Perl and why not Python or Ruby or something else. Honestly, I don’t have a really good answer for you. I tried (unsuccessfully) to teach myself Perl a couple of years ago, so I still have the O’Reilly Learning Perl book. Rather than spending money to learn some other scripting language, it seemed reasonable to revisit Perl again and just leverage the resources I already have. You might see a few Perl-related posts here and there as I work through Learning Perl, but I’ll try not to bore you with elementary stuff.

2. I’m going to learn German. Same scenario here—many people have asked why German and why not Spanish or French. I do have an answer this time: I seem to be spending a fair amount of time in Vienna, so German seemed to make sense. I also have a series of customer meetings planned in Germany in the first quarter of this year. Plus, German is completely new and different than anything I’ve learned before, and I wanted to challenge myself to learn and think in new ways. It’s unlikely that this will find its way into any blog posts, but you never know…

3. I’m going to become much more familiar with the Xen hypervisor. I haven’t yet decided if I’ll focus strictly on the open source version of Xen or Citrix XenServer; I’m open to suggestions there. No, this doesn’t mean that I’m abandoning VMware or anything like that; I just want to expand my knowledge. You can’t simply discount Xen; after all, Amazon EC2 is built on Xen. Along with this dive into Xen, I’ll also be looking very closely at Open vSwitch and OpenStack. I’d expect that a great deal of this education will eventually end up in various blog posts here.

4. I’m going to pursue my CCNP. I “re-achieved” CCNA last year, and this year I’m pursuing my CCNP. As with Xen, I’m confident that the learning curve required to move closer to (or even achieve) CCNP will result in a number of related blog posts on various networking technologies or concepts.

I do have a few other projects planned for this upcoming year, but I’m not quite ready to discuss those publicly yet. At least one of these other projects will be something new that I haven’t done before. Stretching myself and my skills/experience in new directions is a bit of a theme this year.

If you have any tips/tricks/advice to share on any of these upcoming projects, or if there are specific things related to these projects that you’d like to see blogged about here, please let me know in the comments. Thanks, and I hope that 2012 is going to be as exciting for you as it will be for me!

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

Some Projects for 2012

• My Milestone Moment
• Listing Unique Projects Used by MailTags
• Open Source on Mac OS X
• Setting VMware ESX vSwitch Load Balancing Policy via CLI
• Vote Early (But Don’t Vote Often)

With the announcement of VXLAN at VMworld 2011, a new question seems to have arisen: can I use VXLAN instead of (insert some other protocol here) to create my stretched L2 networks? In this post, I’d like to compare the use of VXLAN with OTV (Overlay Transport Virtualization) for that very purpose. Of course, since VXLAN hasn’t actually been released, the discussion is partially theoretical.

My primary focus in this post will be how each of these protocols handles traffic patterns in the course of addressing the need for L2 connectivity over routed L3 networks.

First, let’s look at VXLAN. The figure below is taken from my revised L3 connectivity with VXLAN post, which I encourage you to read for more details.

As you can see, once a VM inside a VXLAN segment is migrated to a new network, the traffic “trombones” back and forth across the VXLAN segment because all traffic has to pass through a single vShield Edge (VSE) instance. This brings up a key limitation of VXLAN that I think is important to point out: VXLAN has an innate dependency on VSE, and VSE cannot be made redundant. That’s right—you can’t have VSE-specific failover functionality; instead, you have to rely on vSphere HA, VM Monitoring, and other features. That means failover times in the minutes, not seconds. What do you think that will do to network connections?

Now, let’s compare VXLAN’s L3 connectivity with OTV. First, here’s a diagram to show connectivity with OTV before a VM is migrated to the second site:

No real surprises here. I’ll just point out here that a typical OTV deployment following “recommended practices” will use redundant Nexus 7000 switches, as shown here. That’s a key advantage that OTV has over VXLAN—the ability to provide redundancy is there and redundancy is easily built into the solution, with failover times in the seconds (or better).

Now, take a look at the post-migration traffic flows with OTV:

In case you didn’t notice it, let me point out the obvious: note the lack of traffic tromboning here. Here’s how it’s accomplished (and documented in this blog post by Ron Fuller, aka @ccie5851 or VDCBadger to his friends):

• Each Nexus 7000 pair runs HSRP.
• The HSRP hello packets are filtered (blocked) from the OTV interfaces. This keeps the HSRP pairs in each data center from knowing about the pair in the other data center.
• Each HSRP pair runs the same virtual IP (the default gateway for the 10.1.1.0/24 subnet).

In this configuration, once the VM migrates to the second site the HSRP pair at the second site won’t need to send traffic across the OTV link to reach the migrated VM. This appears to be a significant advantage to OTV—a greater knowledge of the routing topology allows OTV to be more intelligent about how traffic should be directed across/around the network.

<aside>Of course, this doesn’t address L3 routing concerns from subnets not directly attached to the Nexus 7000 pairs. For that, we’d need something like LISP.</aside>

As I see it—and networking experts are welcome to jump in if I’m mistaken—this gives OTV two key advantages over VXLAN:

1. OTV, because it is running on physical networking equipment, is more intelligent than VXLAN about how traffic is directed/routed in/around/across a network. This can result in more efficient utilization of a data center interconnect as a result of reduced “traffic tromboning.”
2. OTV, because it is running on physical networking equipment, can provide better redundancy and faster failover than VXLAN (which relies on single instances of VSE).

It’s entirely possible that if VXLAN ever makes it into physical network equipment that these advantages of OTV will be nullified.

It’s also important to point out that while OTV and VXLAN have some overlap in functionality they are partially targeted at solving different problems. While both protocols address L2 connectivity across L3 networks, VXLAN also addresses the exhaustion of the VLAN address space in larger networks (especially service provider networks). This is an issue that OTV does not try to address. However, it seems to me that OTV would co-exist better with a solution like Q-in-Q, which could (as far as I can tell) address the VLAN ID exhaustion issue.

Once again, I encourage network experts to chime in and share their views. If I’ve misstated something, please let me know. Questions, thoughts, and comments are always welcome.

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

OTV and VXLAN Layer 3 Connectivity Compared

• Revisiting VXLAN and Layer 3 Connectivity
• VXLAN and Layer 3 Connectivity
• Examining VXLAN
• Technology Short Take #15
• TA2384 – Deploying the Nexus 1000V

The responsiveness of my View desktop is significantly improved over RDP. Under RDP, browsing any sort of Web site—and accessing various internal-only sites is a key use for my corporate View desktop—was just downright painful. With the new PCoIP-enabled Mac client, it’s drastically better. Pages redraw much more quickly, and the browser is much more responsive.

Aside from the much-improved performance granted by the PCoIP support, a few other things stand out:

• It’s nice to see VMware fully embrace the idea of developing for the Mac—no installer package, just open the DMG and drag-and-drop the application into your Applications folder. The new client also offers Lion full-screen support as well.
• The new client no longer requires the Microsoft RDP Client installed. (However, note that if you need RDP connectivity to Windows 7, the new client won’t support that just yet. For that, you’ll need to use the previous generation VMware View client along with the Microsoft RDP Client.)
• You can easily resize your desktop by simply resizing the window. That’s a little thing, I know, but it’s still handy.

Overall, it’s great to see VMware working hard to expand endpoint availability. If I understand correctly, VMware also released updated clients for the iPad and Android as well, both of which also support PCoIP (the View client already supported PCoIP and I’ve used that before as well). Now we just need a PCoIP-enabled client for Linux and we’re good to go!

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

VMware View Client for Mac with PCoIP

• The Right vSphere Design Perspective
• Changing RDP Settings in VMware View Open Client for Mac
• Partner Exchange 2010 Session TECHDV0721
• RDP Printer Redirection with VMware View on a Mac
• Mac RDP Client Wishlist

For those that aren’t familiar, UIM has two flavors:

• UIM/Provisioning (also referred to as UIM/P), which is tasked with handling provisioning/de-provisioning tasks in a Vblock. This would include tasks like deploying UCS B-series blades, zoning FC fabrics, and setting up storage pools.
• UIM/Operations (also referred to as UIM/O) is tasked with providing near real-time visibility into the Vblock, as well as root cause and impact analysis.

In addition to support for UIM/P 3.0 (more info here) and all associated Vblock types, this latest release of UIM/O adds the following features:

• Model-based deterministic automated root cause analysis for faults in a Vblock environment
• Automated impact analysis that visualizes impact on higher-order abstractions such as vApps, UIM Services (these are defined within UIM/P) and Vblocks
• Event forwarding via SNMP traps to enable northbound integration
• Automation of trap reception from MDS and Nexus switches
• Saving and restoring user preferences

As with UIM/P, the new version of UIM/O is available to authorized users on Powerlink:

Home > Support > Software Downloads and Licensing > Downloads E-I > Ionix Unified Infrastructure Manager/Operations

Documentation for UIM/O 3.0 is also available on Powerlink:

Home > Support > Technical Documentation and Advisories > Software ~ E-I ~ Documentation > Ionix Family > Ionix for Data Center Automation and Compliance > Ionix Unified Infrastructure Manager/Operations > 3.0 and Service Packs

(Think that’s a deep enough structure to navigate?)

Enjoy!

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

UIM/Operations 3.0 Now GA

• EMC Unified Storage Plugin Version 2 Now Available
• New Version of UIM/P
• Some Vblock Posts
• Some EMC Product Updates
• VMware Lab Manager 3.0 Released

Networking

The number of articles in my “Networking” bucket continues to overflow; I have so many articles on so many topics (soft switching, OpenFlow, Open vSwitch, MPLS) that it’s hard to get my head wrapped around all of it. Here are a few posts that stuck out to me:

• Ivan Pepelnjak has a very well-written post explaining the various ways that virtual networking can be decoupled from the physical network.
• I stumbled across a trio of articles by Denton Gentry on hash tables (part 1, part 2, and part 3). This is an interesting perspective I hadn’t considered before; as we move more into software-defined networks (SDNs), why are we continuing to use the same mechanisms as before? Why not take advantage of more efficient mechanisms as part of this transition?

Servers/Operating Systems

• Nigel Poulton and I traded a few tweets during HP Discover Vienna about SCSI Express (or SCSI over PCIe, SoP). He wrote up his thoughts about SoP and its future in the storage industry here. Further Twitter-based discussions about fabrics led him to say that HP buying Xsigo would bring the competition back against UCS. I’m not so sure I agree. Xsigo’s server fabric technology/product is interesting, but it seems to me that it’s still adding layers of abstraction that aren’t necessary. As SR-IOV, MR-IOV, and PCIe extension matures, it seems to me that Ethernet as the fabric is going to win. If that’s the case, and HP wants to bring the hurt against UCS, they’re going to have to invest in Ethernet-based fabrics.
• Speaking of UCS, here’s a “how to” on deploying the UCS Platform Emulator on vSphere. You might also like the UCS PE configuration follow-up post.
• Here’s what looks to be a handy Mac OS X utility to track how long until your Active Directory password expires. Sounds simple, yes, but useful.

Storage

• Andre Leibovici bucks the “common wisdom” and recommends that EFDs should be used for the linked clones, not the base replica. I can’t really argue with his recommendation; it’s based on a pretty thorough analysis of I/O patterns against a VMware View environment. It’s a great article for any architect attempting to design a storage solution for a View environment.
• Andre also conducts a good analysis of the effectiveness of FAST Cache in VDI environments that’a also worth a read.
• A “black box” for storage? Interesting idea—more information is available here.

Virtualization

• Jason Boche, after some collaboration with Bob Plankers, wrote up a good procedure for expanding the vCloud Director Transfer Server storage space. It’s definitely worth a read if you’re going to be working with vCloud Director.
• Microsoft has released version 3.2 of the Linux Integration Services for Hyper-V. The new release adds integrated mouse support, updated network drivers, and fixes an issue with SCVMM compatibility.
• Julian Wood, who I had the opportunity to meet in Copenhagen at VMworld 2011, has published a four-part series on managing vSphere 5 certificates. Follow these links for the series: part 1, part 2, part 3, and part 4.
• Thinking of deploying Oracle on vSphere? You should probably read this three-part series from VMware’s Business Critical Applications blog: part 1 is here, part 2 is here, and part 3 is here.
• I’m so used to dealing with VLANs in a vSphere environment, I didn’t consider the challenges that might come up when using them with VMware Workstation. Fortunately, this author did—read his post on mapping VLANs to VMnets in VMware Workstation.
• I thought that this article on virtual disks with business critical applications would be a deep dive on which virtual disk formats (thin, lazy zeroed, eager zeroed) are best suited for various applications. While the article does discuss the different virtual disk formats, unfortunately that’s as far as it goes.
• Fellow VMware vSphere Design co-author Forbes Guthrie highlights an important design concern with AutoDeploy: what about a virtual vCenter instance? Read his full article for the in-depth discussion.
• This post by William Lam gives a good overview of when vSphere MoRefs change (or don’t change).
• Here’s a good explanation why NIC teaming can’t be used with iSCSI binding.
• Cormac Hogan also posted a nice overview of some new vmkfstools enhancements in vSphere 5.
• Terence Luk posts a detailed procedure to help recover VMware Site Recovery Manager in the event of a failure of one of the SRM servers. Good information—thanks Terence!

And that’s it for this time around. Feel free to add your thoughts in the comments below—all comments are welcome! (Please provide full disclosure of vendor affiliations/employment where applicable. Thanks!)

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

Technology Short Take #18

• Technology Short Take #12: Networking Edition
• Technology Short Take #4
• Technology Short Take #16
• Technology Short Take #19
• Technology Short Take #13

The “fatal flaw” was that I was working under the impression that we’d have to change network address translation (NAT) mappings on the vShield Edge (VSE) instance that was handling NAT for a particular VXLAN segment. As a result of this incorrect thinking, I stated that VXLAN broke Layer 3 connectivity. As it turns out, I was wrong.

Instead—and this makes perfect sense now that my flawed thinking was pointed out—the VSE instance continues to serve as the default Layer 3 gateway for the workload(s) inside the VXLAN segment.

Consider this diagram, which shows how a workload external to a VXLAN segment communicates with a workload inside a VXLAN segment:

Note that in this diagram, the Linux workload outside the VXLAN segment communicates via the VSE instance handling NAT for that particular VXLAN segment. The VSE instance (VSE 1) passes that communication to the internal workload, and the return traffic follows the same path. Layer 3 connectivity outside of the VXLAN segment is handled via traditional/normal Layer 2/3 methods.

Now consider this diagram, which shows the same communication, but after the Windows-based workload inside the VXLAN segment has now migrated to a different location:

Note that even though the Windows-based workload inside the VXLAN segment now resides on a completely separate VTEP (ESXi 2, in this case), the traffic from the Linux-based workload outside the VXLAN segment continues to move through VSE 1. That’s because VSE 1 is still the Layer 3 default gateway for the IP subnet inside the VXLAN segment. Therefore—and this is where I was wrong earlier—Layer 3 connectivity is not broken, but it does have to “horseshoe” across to the other data center and then back again, as illustrated above. This is the classic traffic pattern that we see with other overlay technologies, like OTV.

For me, while this addresses Layer 3 connectivity after a migration with VXLAN, it does bring up other questions:

• How does one provide redundancy at the VSE level? Is there VRRP support in VSE, or an equivalent function?
• Because Layer 3 connectivity is maintained, what now is the role of OTV? Is OTV relegated to handling Layer 2 extensions only for non-virtualized workloads?
• How do we now propose to handle the “horseshoe” routing issue? It would seem to me that the only way to address this would be to port support for LISP (or an equivalent protocol) into VSE.

Feel free to post any questions, thoughts, or corrections in the comments below. Thanks!

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

Revisiting VXLAN and Layer 3 Connectivity

• VXLAN and Layer 3 Connectivity
• OTV and VXLAN Layer 3 Connectivity Compared
• Technology Short Take #15
• Examining VXLAN
• VSP2117: Virtualization-Aware Datacenter Networks