Nexus

You are currently browsing articles tagged Nexus.

Recent Cisco Product Launch

Monday, February 6, 2012 in Networking by slowe | 5 comments

Cisco recently launched a number of new products and new versions of products aimed at showing Cisco’s dedication and innovation in network switching. You can get Cisco’s summary of the products here. I’ll start with the hardware-focused announcements.

Hardware-Focused Announcements

Cisco’s announcements on the hardware side primarily centered around new switching capabilities in the form of 40/100 Gigabit Ethernet (GE) cards for both the Nexus 7000 series platform as well as a 40 GE card for the Catalyst 6500 series. (The 40 GE card for the Catalyst 6500 series does require the newer Supervisor Engine 2T, however.)

<aside>Did you know that the 40/100 GE specification, 802.3ba, was ratified in June 2010? I didn’t realize it has been ratified that long.</aside>

For the Nexus 7000 series, Cisco unveiled two cards:

  • The M2-Series 6-port 40 Gigabit Ethernet Module with XL Option (how’s that for a mouthful?) sports, as the name suggests, 6 non-blocking 40 GE ports. With 16 of these blades in the 18-slot Nexus 7018, that provides up to 96 ports of 40 GE connectivity. The “XL Option” in the name of the card enables the card—in conjunction with the Scalable Feature License—to support more IPv4 routes (up to 1 million, depending on several factors), more IPv6 routes (up to 350,000, again depending on several factors), and more access control list (ACL) entries. These increased route and ACL limits could be useful in environments with multiple Virtual Routing and Forwarding (VRF) or multiple Virtual Device Context (VDC) instances. Based on the Cisco data sheet, it looks like this card can work with either Fabric-1 or Fabric-2 modules, although you’ll need Fabric-2 modules for the most throughput.
  • The M2-Series 2-port 100 Gigabit Ethernet Module with XL Option provides two non-blocking 100 GE ports. The “XL Option” functions in the same way as with the 6-port 40 GE card, and it does work with both Fabric-1 and Fabric-2 modules. Here’s the official Cisco data sheet.

Based on the data sheet, it looks like both of these cards will require version 6.1 of NX-OS, which—to my knowledge—is a brand-new release. (Version 6.0 of NX-OS for the Nexus 7000 series was released in late December.)

One interesting note about the 40 GE card is that it supports the use of a breakout cable that allows a single 40 GE port to support four 10 GE connections. This is true for both the Nexus 7000 and Catalyst 6500 cards, as far as I can tell. (Cisco references a FourX connector for the Catalyst 6500 card, but does not reference the same connector for the Nexus blade, instead simply mentioning a “breakout cable”.)

Cisco also introduced the Catalyst 4500-X, a fixed configuration 10 GE aggregation switch. They mentioned “40 GE readiness,” but it’s not clear when 40 GE uplinks will make their way to this particular platform.

Rounding out the hardware announcements was the Nexus 3064-X, a follow-up the low-latency Nexus 3000 series of switches introduced some time ago. This version offers lower power consumption and additional reductions in switching latency. The specific switching latency reductions were not specified anywhere that I found.

Software-Focused Announcements

The software-focused announcements were primarily centered around the Nexus 1000V/1010 and a new feature called Easy Virtual Network (EVN).

  • A new version of the Nexus 1000V was announced that supports VXLAN (Virtual Extensible LAN). I’ve discussed VXLAN extensively (see here), as have others in the industry, so I won’t rehash that again.
  • Also of note is that the Cisco Virtual Security Gateway (VSG) will offer zone-based firewalling services to VMs on VXLAN segments.
  • The Nexus 1010-X is a “beefed up” version of the Nexus 1010 (yes, I know this is technically a hardware product), intended to support more virtual networks. See here for more information on the differences between the Nexus 1010 and the Nexus 1010-X.
  • Easy Virtual Network (EVN) is the most interesting of the software-based announcements (to me, at least). Cisco touts EVN as “fully compatible with established standards, including Multiprotocol Labl Switching (MPLS), MPLS VPN over IP (multipoint generic routing encapsulation, also known as mGRE), Multi-Virtual Route Forwarding (also known as VRF-Lite), and others.” (More information available here.) However, it appears that EVN doesn’t actually use any of these mechanisms. In fact, it’s unclear to me exactly what mechanism EVN does use. The data sheet (linked above) mentions the use of a VNET tag, and indicates that the VNET tag is stored in the 802.1q VLAN ID field. This looks like Cisco is creating yet another Layer 3 VPN solution, instead of leveraging existing solutions. Why not add VXLAN support to the hardware switches instead of creating EVN? Maybe I’m completely missing the mark here…feel free to correct me (courteously, of course!).

Why This Matters to You

All these product announcements and new product versions are pretty cool, but you might be wondering, “Why does this matter to me?” Good question. Here are my thoughts:

  • The 40 GE and 100 GE cards are important in data centers where we are seeing increased deployment of 10 GE to the servers. Once motherboard manufacturers start using 10 GE LoM (LAN on Motherboard) ports, the deployment of 10 GE to servers in data centers will naturally increase. Deploying 40 GE and 100 GE uplinks in 10 GE-heavy environments makes sense (depending on the details, naturally).
  • You already knew the VXLAN-capable 1000V was on the way (this was alluded to in the original VXLAN announcement at VMworld 2011), so no real surprises there.
  • The Nexus 1010-X simply allows you to run more VSBs (virtual service blades), such as the Nexus 1000V VSM (virtual supervisor module). If you’re a Nexus 1000V customer, you might have already started investigating the use of the Nexus 1010 to host the VSMs. Large customers (service providers, perhaps?) had a need for more VSBs on a single Nexus 1010, hence the Nexus 1010-X.
  • EVN…well, I’m stuck on EVN. I certainly see the need for simpler separation of traffic, but again I must ask why Cisco appears to be creating something new instead of re-using protocols that are perfectly suited for this purpose? Maybe I need a networking expert to explain it to me. (When I understand it, I’ll post an explanation that everyone else can understand. Fair?)

As always, feel free to post any clarifications or corrections in the comments below. I’d love to hear from any networking gurus on any of the points that I raised in this article.

Tags: , ,

BRKDCT-2121: Virtual Device Context Design and Implementation Considerations

Wednesday, July 13, 2011 in Networking by slowe | 3 comments

I joined this session late (a last minute change from the UCS VM-FEX session). This session is on VDC design considerations with the Nexus 7000, presented by Ron Fuller, CCIE #5851 (@ccie5851 on Twitter).

A VDC (virtual device context) is a “superstructure” that encapsulates (or encompasses) both VLANs and VRFs. Each VDC maintains its own VLAN table and its own VRF instances. There are some resources that are global (not dedicated to a particular VDC); these would include things like a boot image configuration. Other resources are dedicated to a VDC. This is stuff like VLANs, Layer 2 and Layer 3 ports, and IP address space. There are some shared resources, like the out-of-band (OOB) Ethernet management port.

VDCs are a licensed feature within NX-OS; they are part of the Advanced license. Up to 4 VDCs are supported. (Is the VDC limit a software limit, a hardware limit, or a license limit?) Note that 120 day evaluation licenses are available in NX-OS so that you can test features like VDCs, OTV, etc.

There was a question about the “Enhanced L2″ license; this refers to FabricPath (see my FabricPath session blog for more information).

Note that VDCs are considered PCI compliant and are FIPS 140-2 certified.

Even if you don’t buy the Advanced license, you still have a VDC: the default VDC. The default VDC is where you create other VDCs, where you perform NX-OS upgrades, where Control Plane Policing (CoPP) occurs, and where resource allocation (interfaces and memory) occurs. Any non-default VDCs are fully functional (of course), and changes in the non-default VDC (which would be VDCs 2-4) only affect that VDC (with the exception of “cascading” impacts due to peer adjacencies, connections, etc.). Each VDC has its own discrete configuration file, discrete RBAC, discrete TACACS, discrete SNMP, etc.

As of NX-OS 5.1, there are now “module-type” modes. This parameter defines the behavior for each VDC. This allows you to specify an m1 mode (can contain M1 modules), m1-xl (can only contain M1-XL modules), or f1 mode (can contain F1 modules). You use these modes with the limit-resource module-type command.

As of NX-OS 5.2, you can define a storage VDC. The storage VDC is a “virtual MDS” within the Nexus 7000. The storage VDC consumes a domain ID, participates in zoning and VSANs, FC alias, IVR, fabric binding, etc. The storage VDC also provides FCoE ISLs (VE_ports) to other FCoE switches. Only a single storage VDC is allowed, it does not require the Advanced license, but does count toward the total VDC count.

Keep in mind that only F1 modules support FCoE; therefore, only F1 modules would be allowed in a storage VDC.

NX-OS has the ability to allocate resources on demand; this allows you to allocate resources to individual VDCs based on the VDC’s specific requirements. You can also fine-tune the resource allocation.

Although you can assign ports on a per-VDC basis, some modules have groups of ports that share ASICs. In those instances, you have to allocate all the ports that share an ASIC. For example, the N7K-M132XP-12 has groups of 4 ports that share an ASIC; therefore, these ports have to be allocated in groups of 4. The N7K-F132XP-15 card, on the other hand, shares an ASIC for every 2 ports, so ports are allocated to VDCs in groups of 2. The N7K-M108X2-12L card can assign ports individually. All M1 48 port line cards can have their ports allocated individually, although there is a recommendation to align port allocation in groups of 12. You also cannot split a FEX between VDCs; all the ports on a FEX belong the VDC of the uplink port into the Nexus 7000.

How do you allocate ports to a VDC? In config mode, use the vdc <Name> command to enter a VDC, and then use the allocate interface command. You can also use the show vdc membership command to show VDC allocation.

Prior to NX-OS 5.2, an interface allocated to a VDC isn’t visible from any other VDC, including the default VDC. NX-OS 5.2 enables an exception to this to enable FCoE initiators coming in on one VDC to see targets on a storage VDC by sharing interfaces between an Ethernet VDC and a storage VDC. The Nexus 7000 automatically splits traffic based on Ethertype (0×8914 and 0×8906, FIP and FCoE, are automatically redirected to the storage VDC). Shared interfaces must be on N7K-F132XP-15 modules, and the ports must be configured as a 802.1Q trunk. Use the allocate shared interface command to configure shared interfaces.

There is no soft cross-connect over the backplane to connect VDCs; all communication has to go through ports on the front panel. There are no restrictions on module types (M1 to F1, etc.) If you are using vPC or vPC+ between VDCs, make sure the domain IDs are unique. All the interfaces in a vPC peer link must come from the same module type.

Creating a VDC is accomplished using the vdc <New Name> command. Add type storage to that command to create a storage VDC (and that will automatically limit the module types as stated earlier). The show vdc <New Name> detail will give you more details about the specified VDC.

To navigate between VDCs, use the switchto vdc <Name> command; to switch back to the default VDC, use the switchback command. Use of the switchto command can be regulated via RBAC (which does not stand for Rogue Badger Access Control, by the way). You can only use the switchto command to move from the default VDC to a non-default VDC; you can’t jump between non-default VDCs.

Non-default VDCs can be suspended, resumed, reloaded, or restarted. Use the reload command to reload a VDC; use the vdc <Name> suspend command to suspend a VDC. Reloading the default VDC reloads all VDCs.

Some VDC leading practices:

  • Reserve the default VDC for administrative functions.
  • On VDC 1 assign accounts with minimum privileges necessary to perform operational tasks.
  • Use a linecard per VDC for improved HA and VDC isolation.
  • Customize VDC HA policy and resource configurations as necessary.

Ron now moves on to a discussion of consolidation with VDCs. Consolidation is one of those areas where you have to consider the trade-offs between various network configurations. VDCs do enable 4:1 consolidation while still maintaining hierarchy. Naturally, there are risks (a catastrophic hardware failure will take out all the VDCs). Other considerations:

  • VDC to forwarding engine mapping
  • A single chassis is still a single point of failure
  • MAC table sizing is bound to the “lowest common denominator”
  • There are a limited number of SPAN sessions

Not only can you use VDCs for consolidation, you can also use VDCs for segmentation. Perhaps you want to use a pair of Nexus 7000s for core, DMZ, and Internet edge traffic. Using VDCs can make this possible. (In my mind this is just another consolidation scenario).

NX-OS 5.2 introduces support for MPLS, which means that each VDC can operate as a separate MPLS router (label switching router, LSR). This offers the opportunity to consolidate multiple layers of PE router and P routers.

VDC also works well with OTV. OTV requires an OTV edge device, and there is no universal agreement upon where the OTV edge device should be placed. OTV does require separation of the SVI routing and the OTV encapsulation; this is ideally accomplished using VDCs instead of multiple physical appliances (including “on-a-stick” variations). Ron walks through several different scenarios and ways in which VDCs could be incorporated into an OTV design.

Next Ron shifts gears to discuss VDCs with FCoE. The use of VDCs allows us to further leverage fabric/network convergence beyond just the access layer. While it won’t necessarily reduce the number of links between switches, it will reduce the overall number of switches and still allow us to maintain SAN A/SAN B separation, role-based access, etc.

The next technology Ron looks at with VDCs is FabricPath. I wasn’t able to capture all of these information. Ron then wrapped up the session.

Tags: , , ,

Connecting Cisco Catalyst 2960-S to Nexus 5010

Wednesday, April 20, 2011 in Networking by slowe | 11 comments

As part of the all-star team that is currently heads down in preparation for some cool stuff that will be at EMC World 2011 in just a couple of weeks, today I needed to connect a Cisco Catalyst 2960-S to a Nexus 5010 over a 10GbE connection. Simple enough, right?

And it was simple, too—configure each side as a VLAN trunk, make sure the port on each side is enabled (not administratively down), and plug in a Cisco-branded TwinAx cable. All set! Well…except for the fact that only certain “versions” of the TwinAx SFP+ cables are supported with the 2960-S (see this page). Fortunately, someone at Cisco was smart enough to include the version number in the part number on the SFPs on the end of the TwinAx cables, so it only took a few minutes to find the right version of the cable. Pull the old cable, put in the new cable.

Wait, it’s still not working. As it turns out, the port on the 2960-S was put into an “error-disabled” state because of the unsupported transceiver on the pre-v2 TwinAx cable (I believe the command I used to find this was show interfaces error-disabled). Fortunately, that’s a quick fix: simply use the shutdown command to put the port into an administratively down state, then use the no shut command to bring it back up again. It’s at that point that the switch checks the transceiver again and realizes that it’s supported.

Key takeaways?

  • There are different versions of TwinAx cables (and their associated transceivers). Who knew? (OK, no snarky comments out there.)
  • Certain switches only support certain versions of these TwinAx cables.
  • The only way (or is it?) to get a port out of err-disable state is to use shutdown and then no shutdown.

Every day is a learning experience. That’s what makes life fun!

Tags: , ,

Cisco’s Data Center Launch

Wednesday, March 30, 2011 in Networking, Virtualization by slowe | 19 comments

Cisco had a pretty major product/technology launch today. I was briefed on the product launch some time ago—one of the perks of being a “leading blogger”—and so it was great to see this stuff finally come to light. I haven’t had the chance to read some of the other blog posts on the topic (I know there have been several), so I apologize for any duplication.

First, let’s take a quick look at the “new product” news included in the launch:

  • Cisco is launching the Nexus 3000, a new member of the Nexus family. It’s a high density, ultra-low latency 1RU switch that supports both 1GbE as well as 10GbE. All ports are wire rate and non-blocking. At first glance, this seemed to be a bit of a conflict with some of the Catalyst switches (like the 4948, perhaps?), but I think the distinction here is the low latency target (approximately 1 usec port to port). It also makes sense if customers are interested in standardizing on switches running NX-OS instead of a mix of NX-OS and IOS.
  • Cisco is also launching new Nexus 5500 series switches, the Nexus 5548UP and Nexus 5596UP. These are very much like the other members of the Nexus 5500 family, except that the “UP” designation indicates that they will support “Unified Ports”. Unified Ports are ports that can support either Fibre Channel (supporting up to 8Gbps FC), Fibre Channel over Ethernet (at 10Gbps), or Ethernet at 1Gbps. You will need to swap SFPs (for now, at least) and reconfigure the port, and you must cycle/reset the module in which the ports reside in order to switch personality. (It’s my understanding that future improvements will require only cycling the specific port being switched.) Personally, I think the Unified Port functionality is extremely useful and I’m glad to see Cisco deliver it.
  • Cisco is also announced a new C-series rack mount server, the C260 M2. This is a dual-socket server running Intel Westmere CPUs, supporting up to 64 DIMM slots (using Cisco’s Memory Expansion technology) and supporting up to 16 HDDs or SSDs. It’s a pretty beefy server. From a virtualization perspective, the expanded memory footprint is pretty useful, but I’m not so sure that the 16 drive bays is much of a selling point. I’d love to hear others’ thoughts on that matter.
  • Also in the new product lineup are some new Catalyst 6500 modules, an ACE-30 module, an ASA service module, and a ES-40 40Gb DCI module for high-speed data center interconnects.
  • Finally, Cisco is launching an FCoE module for the MDS, which will allow customers to integrate FCoE into their networks while preserving their investment in the MDS infrastructure. On its own, this is interesting, but when coupled with other announcements…well, read on for more details.

However, the launch isn’t just about new products; if it were, it would be pretty boring, to be honest. The news included in the launch about the expansion of existing technologies is, in my mind, far more significant:

  • First, Cisco is stepping away from the “VN-Tag” moniker and focusing instead of the IEEE standardization of that functionality, a la 802.1Qbh. That’s a good move, in my opinion; they’re also going to be adding 802.1Qbg support in the future. Not such a good move (again, in my opinion) is the rebranding effort around VN-Tag and VN-Link, which are now going to be called Adapter FEX and VM-FEX. I don’t know that this new naming convention is going to be any less confusing or any more clear than the previous strategy. It is a bit more technically accurate, at least, since—if you read my post on network interface virtualization—you know that the Cisco Virtual Interface Controller (VIC), aka “Palo”, is really just a fabric extender (FEX) in a mezzanine card form factor. So, calling this Adapter FEX is a bit more accurate. VM-FEX….well, this still isn’t so clear. If any Cisco folks want to help clear things up, feel free to jump in by posting a comment to this post.
  • Cisco is adding FCoE support to the Nexus 7000 via the F1 line cards. This brings FCoE support directly to the Nexus 7000, which is a move that many expected. Along with the FCoE support, Cisco is also introducing the idea of a new type of virtual device context (VDC), the storage VDC. A storage VDC will process all FCoE traffic passing through the switch, in a completely separate fashion from LAN traffic (which would run in a separate LAN VDC). At least initially, Cisco will require the use of a storage VDC to use FCoE with the Nexus 7000; that might change over time. As with the introduction of the FCoE module for the MDS 9500, this news is interesting, but is really only useful in conjunction with other announcements. Specifically…(drum roll please)
  • In perhaps the biggest announcement of the event, Cisco is now supporting full multi-hop FCoE topologies. As I understand it, there will be a new release of NX-OS that will support the creation of VE_ports and enable multi-hop FCoE topologies (up to 7 hops supported). This functionality will exist not only on the Nexus 5000/5500, but also on the Nexus 7000 and on the FCoE module of the MDS 9500. As far as I know, this also means that any Nexus 2000 series fabric extenders that support FCoE will also now support multi-hop FCoE via their upstream Nexus switch. Cisco is going to require dedicated FCoE links between switches, at least at first, and as I mentioned earlier will require the use of a storage VDC on the Nexus 7000. I believe that this is probably the most significant announcement being made, and when taken together with other FCoE-related announcements like the FCoE module on the MDS 9500 and FCoE support on the Nexus 7000, opens up lots of new possibilities for FCoE and Unified Fabric in the data center. I, for one, am really excited to dive even deeper into the design considerations around multi-hop FCoE and Unified Fabric. Any network gearheads interested in doing a brain dump on multi-hop FCoE for me?
  • Equally important in the long-term but (apparently) not making a big impact immediately is LISP (Location ID/Separation Protocol). I’ve been talking LISP with Cisco for a while now (as I suspect many of you have), so it’s good to see the official announcement. Lots of people confuse the purpose/role of LISP when compared to OTV; they are both equally important but in very different ways. Further, LISP does not replace OTV (or vice versa). I’ll probably try my hand at a separate blog post to specifically discuss these two technologies and how the plan is for them to work hand-in-hand with each other for workload mobility. For now, it should suffice to say that OTV addresses Layer 2 connectivity between data centers while LISP helps the rest of the network more efficiently understand and adapt to the Layer 2 connectivity between data centers. Both are necessary.

There were a few other tidbits—like the ability to run up to 6 Nexus 1000V VSMs on the Nexus 1010, or support for the Virtual Security Gateway (VSG) on the Nexus 1010—but this covers the bulk of the information.

All in all, it’s exciting to see some of these technologies coming to light, and I’m really excited to see how the data center is going to evolve over the next couple of years. It’s a great time to be in this industry, especially if you’re a glutton for learning new technologies like me!

As always, I invite and encourage discussion, so if I’ve left something important out or if I’ve misrepresented something, please speak up in the comments (courteously and with full disclosure, where applicable). Thanks!

UPDATE: In response to information gathered via Twitter (I’m @scott_lowe), I’ve updated the information on the 5584UP/5596UP and Unified Ports functionality. Thanks for the great discussion!

Tags: , , , ,

Technology Short Take #11

Thursday, February 17, 2011 in Networking, Storage, Virtualization by slowe | 6 comments

That’s right folks, it’s time for another installation of Technology Short Takes. This is Technology Short Take #11, and I hope that you find the collection of items I have for you this time around both useful and informative. But enough of the introduction—let’s get to the good stuff!

Networking

  • David Davis (of Train Signal) has a good write-up on the Petri IT Knowledgebase on using a network packet analyzer with VMware vSphere. The key, of course, is enabling promiscuous mode. Read the article for full details.
  • Jason Nash instructs you on how to enable jumbo frames on the Nexus 1000V, in the event you’re interested. Jason also has good coverage of the latest release of the Nexus 1000V; worth reading in my opinion. Personally, I’d like Cisco to get to version numbers that are a bit simpler than 4.2(1) SV1(4).
  • Now here’s a link that is truly useful: Greg Ferro has put together a list of Cisco IOS CLI shortcuts. That’s good stuff!
  • There are a number of reasons why I have come to generally recommend against link aggregation in VMware vSphere environments, and Ivan Pepelnjak exposes another one that rears its head in multi-switch environments in this article. With the ability for vSphere to utilize all the uplinks without link aggregation, the need to use link aggregation isn’t nearly as paramount, and avoiding it also helps you avoid some other issues as well.
  • Ivan also tackles the layer 2 vs. layer 3 discussion, but that’s beyond my pay grade. If you’re a networking guru, then this discussion is probably more your style.
  • This VMware KB article, surprisingly enough, seems like a pretty good introduction to private VLANs and how they work. If you’re not familiar with PVLANs, you might want to give this a read.

Servers

  • Want to become more familiar with Cisco UCS, but don’t have an actual UCS to use? Don’t feel bad, I don’t either. But you can use the Cisco UCS Emulator, which is described in a bit more detail by Marcel here. Very handy!

Storage

  • Ever find yourself locked out of your CLARiiON because you don’t know or can’t remember the username and password? OK, maybe not (unless you inherited a system from your predecessor), but in those instances this post by Brian Norris will come in handy.
  • Fabio Rapposelli posted a good write-up on the internals of SSDs, in case you weren’t already aware of how they worked. As SSDs gain traction in many different areas of storage, knowing how SSDs work helps you understand where they are useful and where they aren’t.
  • Readers that are new to the storage space might find this post on SAN terminology helpful. It is a bit specific to Cisco’s Nexus platform, but the terms are useful to know nevertheless.
  • If you like’s EMC’s Celerra VSA, you’ll also like the new Uber VSA Guide. See this post over at Nick’s site for more details.
  • Fellow vSpecialist Tom Twyman posted a good write-up on installing PowerPath/VE. It’s worth reading if you’re considering PP/VE for your environment.
  • Joe Kelly of Varrow posted a quick write-up about VPLEX and RecoverPoint, in which he outlines one potential issue with interoperability between VPLEX and RecoverPoint: how will VPLEX data mobility affect RP? For now, you do need to be aware of this potential issue. For more information on VPLEX and RecoverPoint together, I’d also suggest having a look at my write-up on the subject.
  • I won’t get involved in the discussion around Open FCoE (the software FCoE stack announced a while back); plenty of others (J Metz speaks out here, Chad Sakac weighed in here, Ivan Pepelnjak offers his opinions here, and Wikibon here) have already thrown in. Instead, I’ll take the “Show me” approach. Intel has graciously offered me two X520 adapters, which I’ll run in my lab next to some Emulex CNAs. From there, we’ll see what the differences are under the same workloads. Look for more details from that testing in the next couple of months (sorry, I have a lot of other projects on my plate).
  • Jason Boche has been working with Unisphere, and apparently he likes the Unisphere-VMware integration (he’s not alone). Check out his write-up here.

Virtualization

  • For the most part, a lot of people don’t have to deal with SCSI reservation conflicts any longer. However, they can happen (especially in older VMware Infrastructure 3.x environments), and in this post Sander Daems provides some great information on detecting and resolving SCSI reservation conflicts. Good write-up, Sander!
  • If you like the information vscsiStats gives you but don’t like the format, check out Clint Kitson’s PowerShell scripts for vscsiStats.
  • And while we’re talking vscsiStats, I would be remiss if I didn’t mention Gabe’s post on converting vscsiStats data into Excel charts.
  • Rynardt Spies has decided he’s going Hyper-V instead of VMware vSphere. OK, only in his lab, and only to learn the product a bit better. While we all agree that VMware vSphere far outstrips Hyper-V today, Rynardt’s decision is both practical and prudent. Keep blogging about your experiences with Hyper-V, Rynardt—I suspect there will be more of us reading them than perhaps anyone will admit.
  • Brent Ozar (great guy, by the way) has an enlightening post about some of the patching considerations around Azure VMs. All I can say is ouch.
  • The NIST has finally issued the final version of full virtualization security guidelines; see the VMBlog write-up for more information.
  • vCloud Connector was announced by VMware last week at Partner Exchange 2011 in Orlando. More information is available here and here.
  • Arnim van Lieshout posted an interesting article on how to configure EsxCli using PowerCLI.
  • Sander Daems gets another mention in this installation of Technology Short Takes, this time for good information on an issue with ESXi and certain BIOS revisions of the HP SmartArray 410i array controller. The fix is an upgrade to the firmware.
  • Sean Clark did some “what if” thinking in this post about the union of NUMA and vMotion to create VMs that span multiple physical servers. Pretty interesting thought, but I do have to wonder if it’s not that far off. I mean, how many people saw vMotion coming before it arrived?
  • The discussion of a separate “management cluster” has been getting some attention recently. First was Scott Drummonds, with this post and this follow up. Duncan responded here. My take? I’ll agree with Duncan’s final comment that “an architect/consultant will need to work with all the requirements and constraints”. In other words, do what is best for your situation. What’s right for one customer might not be right for the next.
  • And speaking of vShield, be sure to check out Roman Tarnavski’s post on extending vShield.
  • Interested in knowing more about how Hyper-V does CPU scheduling? Ben Armstrong is happy to help out, with Part 1 and Part 2 of CPU scheduling with Hyper-V.
  • Here’s a good write-up on how to configure Pass-Through Switching (PTS) on UCS. This is something I still haven’t had the opportunity to do myself. It kind of helps to actually have a UCS for stuff like this.

It’s time to wrap up now; I think I’ve managed to throw out a few links and articles that someone should find useful. As always, feel free to speak up in the comments below.

Tags: , , , , , , , , , ,

Technology Short Take #9

Wednesday, December 29, 2010 in Networking, Storage, Virtualization by slowe | 17 comments

Welcome to Technology Short Take #9, the last Technology Short Take for 2010. In this Short Take, I have a collection of links and articles about networking, servers, storage, and virtualization. Of note this time around: some great DCI links, multi-hop FCoE finally arrives (sort of), a few XenServer/XenDesktop/XenApp links, and NTFS defragmentation in the virtualized data center. Here you go—enjoy!

Networking

  • Brad Hedlund has a great post discussing Nexus 7000 connectivity options for Cisco UCS. I’ll include it in this section since it focuses more on the networking aspect rather than UCS. I haven’t had the time to read the full PDF linked in Brad’s article, but the other topics he discusses in the post—FabricPath networks, F1 vs. M1 linecards, and FCoE connectivity—are great discussions. I’m confident the PDF is equally informative and useful.
  • This UCS-specific post describes how northbound Ethernet frame flows work. Very useful information, especially if you are new to Cisco UCS.
  • Data Center Interconnect (DCI) is a hot topic these days considering that it is a key component of long-distance vMotion (aka vMotion at distance). Ron Fuller (who I had the pleasure of meeting in person a few weeks ago, great guy), aka @ccie5851 on Twitter and one of the authors of NX-OS and Cisco Nexus Switching: Next-Generation Data Center Architectures (available from Amazon), wrote a series on the various available DCI options such as EoMPLS, VPLS, A-VPLS, and OTV. If you’re considering DCI—especially if you’re a non-networking guy and need to understand the impact of DCI on the networking team—this series of articles is worth reading. Part 1 is here and part 2 is here.
  • And while we are discussing DCI, here’s a brief post by Ivan Pepelnjak about DCI encryption.
  • This post was a bit deep for me (I’m still getting up to speed on the more advanced networking topics), but it seemed interesting nevertheless. It’s a how-to on redistributing routes between VRFs.
  • Optical or twinax? That’s the question discussed by Erik Smith in this post.
  • Greg Ferro also discusses cabling in this post on cabling for 40 Gigabit and 100 Gigabit Ethernet.

Servers

  • As you probably already know, Cisco released version 1.4 of the UCS firmware. This version incorporates a number of significant new features: support for direct-connected storage, support for incorporating C-Series rack-mount servers into UCS Manager (via a Nexus 2000 series fabric extender connected to the UCS 61×0 fabric interconnects), and more. Jeremy Waldrop has a brief write-up that lists a few of his favorite new features.
  • This next post might only be of interest to partners and resellers, but having been in that space before joining EMC I fully understand the usefulness of having a list of references and case studies. In this case, it’s a list of case studies and references for Cisco UCS, courtesy of M. Sean McGee (who I hope to meet in person in St. Louis in just a couple of weeks).

Storage

Virtualization

  • Using XenServer and need to support multicast? Look to this article for the information on how to enable multicast with XenServer.
  • A couple of colleagues over at Intel (I worked with Brian on one of his earlier white papers) forwarded me the link to their latest Ethernet virtualization white paper, which discusses the use of 10 Gigabit Ethernet with VMware vSphere. You can find the link to the latest paper in this blog entry.
  • Bhumik Patel has a good write-up on the “behind-the-scenes” technical details that went into the Cisco-Citrix design guides around XenDesktop/XenApp on Cisco UCS. Bhumik provides the details on things like how many blades were using in the testing, what the configuration of the blades was, and what sort of testing was performed.
  • Thinking of carving your storage up into guest OS datastores for VMware? You might want to read this first for some additional considerations.
  • I know that this has seen some traffic already, but I did want to point out Eric Sloof’s post on the Xenoss XenPack for ESXTOP. I haven’t had the opportunity to use it yet, but would certainly love to hear from anyone who has. Feel free to share your experiences in the comments.
  • As is usually the case, Duncan Epping has had some great posts over the last few weeks. His post on shares set on resource pools highlights the need to adjust the shares value (and other resource constraints) based on the contents of the pool, something that many people forget to do. He also provides a breakdown of the various vCenter memory statistics, and discusses an issue with binding a Provider vDC directly to an ESX/ESXi host.
  • PowerCLI 4.1.1 has some improvements for VMware HA clusters which are detailed in this VMware vSphere PowerCLI Blog entry.
  • Frank Denneman has three articles which have caught my attention over the last few weeks. (All his stuff is good, by the way.) First is his two-part series on the impact of oversized virtual machines (part 1 and part 2). Some of the impacts Frank discusses include memory overhead, NUMA architectures, shares values, HA slot size, and DRS initial placement. Apparently a part 3 is planned but hasn’t been published yet (see some of the comments in part 2). Also worth a read is Frank’s recent post on node interleaving.
  • Here’s yet another tool in your toolkit to help with the transition to ESXi: a post by Gabe on setting logfile location, swap file, SNMP, and vmkcore partition in ESXi.
  • Here’s another guide to creating a bootable ESXi USB stick (on Windows). Here’s my guide to doing it on Mac OS X.
  • Jon Owings had an idea about dynamic cluster pooling. This is a pretty cool idea—perhaps we can get VMware to include it in the next major release of vSphere?
  • Irritated that VMware disabled copy-and-paste between the VM and the vSphere Client in vSphere 4.1? Fix it with these instructions.
  • This white paper on configuration examples and troubleshooting for VMDirectPath was recently released by VMware. I haven’t had the chance to read it yet, but it’s on my “to read” list. I’ll just have a look at that in my copious free time…
  • David Marshall has posted on VMblog.com a two-part series on how NTFS causes I/O bottlenecks on virtual machines (part 1 and part 2). It’s a great review of NTFS and how Microsoft’s file system works. Ultimately, the author of the posts (Robert Nolan) sets the readers up for the need for NTFS defragmentation in order to reduce the I/O load on virtualized infrastructures. While I do agree with Mr. Nolan’s findings in that regard, there are other considerations that you’ll also want to include. What impact will defragmentation have on your storage array? For example, I think that NetApp doesn’t recommend using defragmentation in conjunction with their storage arrays (I could be wrong; can anyone confirm?). So, I guess my advice would be to do your homework, see how defragmentation is going to affect the rest of your environment, and then proceed from there.
  • Microsoft thinks that App-V should be the most important tool in your virtualization tool belt. Do you agree or disagree?
  • William Lam has instructions for how to identify the origin of a vSphere login. This might not be something you need to do on a regular basis, but when you do need to do it you’ll be thankful you have the instructions how.

I guess it’s time to wrap up now, since I have likely overwhelmed you with a panoply of data center-related tidbits. As always, I encourage your feedback, so please feel free to speak up in the comments. Thanks for reading!

Tags: , , , , , , , , , , ,

Technology Short Take #8

Friday, December 17, 2010 in Networking, Storage, Virtualization by slowe | No comments

Welcome to Technology Short Take #8, my latest collection of item from around the Internet pertaining to data center technologies such as virtualization, networking, storage, and servers. I hope you find something useful here!

Networking

  • A couple weeks ago I wrote about how to connect a Nexus 2148T to a Nexus 5010. What I haven’t actually done yet is connect the Nexus 2148T to dual Nexus 5010 upstream switches using virtual port-channels. This post offers a configuration for just such an arrangement (just be sure to read the follow-up post for a key command to include in the configuration).
  • And speaking of fabric extenders, Brad Hedlund recently posted a great article explaining QoS on the Cisco UCS fabric extender.
  • Erik Smith has posted part 2 of his series on FIP, FIP snooping bridges, and FCFs.
  • This post by Ethan Banks on the scaling limitations of EtherChannel reinforces what I’ve said before about the use of EtherChannel and VMware ESX/ESXi (see this post and this follow-up post). Apparently this misunderstanding about how link aggregation works isn’t just limited to virtualization folks.
  • This article on BPDU Guard and BPDU Filter is a bit deep for the non-expert networkers (like me), but is good reading nevertheless. Since it is recommended that you disable Spanning Tree Protocol for ports facing VMware ESX/ESXi hosts (and here’s the explanation why from our good friend Ivan “IOSHints” Pepelnjak), it’s good to understand which commands to use and at which scope to use them.
  • While link aggregation isn’t a panacea, it can be helpful in a number of situations. However, you really need to consider multi-chassis link aggregation in order to eliminate single points of failure. Ivan Pepelnjak posted a series of articles on multi-chassis link aggregation (MLAG): MLAG basics, MLAG via stacking, and MLAG external brains. I think there’s another post still coming, correct Ivan?
  • This post is written by networking guru Jeremy Gaddis, but it’s really more about UNIX and regular expressions. So in which category does it belong? (Does it really matter?) I guess since it deals with how to use UNIX tools and regular expressions to manipulate networking data I’ll put it in the networking category.
  • Here’s a good post on creating LAN-to-LAN tunnels between a Vyatta router and a Cisco ASA.
  • Joe Onisick has a good write-up on the behavior of inter-fabric traffic in UCS.

Servers

Storage

  • It’s good to see more “virtualization” people getting into storage. Recently, Jon Owings (of “2vcps and a Truck” fame) posted two good articles on storage caching vs. tiering (part 1 and part 2). Jon provides a good vehicle to discuss these technologies, both of which are valuable and both of which have a place in many companies’ storage strategy.
  • Here’s another view on storage tiering vs. caching.
  • And speaking yet again of caching and tiering…here’s some info on FAST (tiering) and FAST Cache (caching).
  • Finally, rounding out this week’s caching and tiering discussions, I have Nigel Poulton’s post on sub-LUN tiering design considerations.

Virtualization

  • Noted virtualization performance guru Scott Drummonds posted a collection of thoughts regarding maximum hosts per cluster. Duncan Epping—who along with Frank Denneman recently published their HA and DRS Technical Deep Dive book—followed up with his own post on the matter. Both Scott and Duncan summarized some of the advantages and disadvantages of both large and small clusters. The real key to understanding the “right” cluster size is, as Duncan points out, an understanding of how best to meet the requirements of the environment.
  • Scott also posted this useful discussion on considerations around VMDK consolidation in virtualized environments.
  • Need to find the IP address of a VM from an ESX host? Try this article, which provides the steps and tools you need.
  • I saw a couple of good articles from Frank Denneman recently. One was on how to disallow multiple VM console sessions; the second was discussing disabling the balloon driver and why it’s generally not a good idea. Frank also posted a piece recently on the interaction between QoS and the adaptive algorithm that DRS uses to determine concurrent vMotions. While I agree that you don’t want to impact DRS’ ability to perform concurrent vMotions to restore cluster balance, it’s also critically important to ensure proper balance in network traffic. You don’t want a single type of network traffic to swamp others. As with many other things in the virtualization arena, just be sure to understand the impact of your decisions.
  • If you need to shape network traffic (like vMotion), here’s a how to document on how it’s done.
  • This article underscores the difficulty that many organizations have in adopting “the cloud”, at least as it pertains to public cloud-based services. Perhaps this is why VMware is so keen on embracing software development tools that help build cloud-enabled applications…
  • I think that esxtop remains an underestimated tool in troubleshooting. If you need to deepen your understanding of this very useful tool, a good place to start—among the many, many resources that are available—would be this presentation. Thanks for posting this, Alan!
  • William Lam has posted a thorough guide to using vi-fastpass with fpauth and adauth. As the vMA grows in importance with the transition to ESXi in the next major release of vSphere, tips and tricks such as this are going to be worth their words in gold. Good job William!
  • Remember how I’ve mentioned before that it’s funny when vendors taking existing technologies and rename them to include the word “virtualization”? That’s the feeling I get from reading this article on Microsoft’s user state virtualization.

It’s time to wrap up now, so I’ll just say that I welcome any feedback, corrections, clarifications, or additions in the comments below. I hope you’ve found something helpful. Thanks!

Tags: , , , , , , , ,

Connecting a Nexus 2148 to a Nexus 5010

Tuesday, November 30, 2010 in Networking by slowe | 6 comments

The Cisco Nexus 2000 series fabric extender (or “fex”) is an implementation of network interface virtualization. Because the Nexus 2000 fabric extender acts as a remote line card to the upstream IV-capable bridge (a Nexus 5000 series switch, typically), all the configuration takes place on the upstream bridge. In this post, I’ll describe how to connect a Nexus 2148T to a Nexus 5010. In reality, the process is incredibly simple and not really worthy of a blog post, but in the interest of completeness I’ll document it here.

The key to making the fabric extender work is the switchport mode fex-fabric command, used on a specific interface to let the Nexus 5000 know that a fabric extender is connected to that port:

nexus(config)# interface eth2/1
nexus(config-if)# switchport mode fex-fabric

You can use the switchport mode fex-fabric command on a specific interface, as shown above, or on a port-channel:

nexus(config)# interface port-channel 2
nexus(config-if)# switchport mode fex-fabric
nexus(config-if)# interface eth2/1
nexus(config-if)# switchport mode fex-fabric
nexus(config-if)# channel-group 2 mode on
nexus(config-if)# interface eth2/2
nexus(config-if)# switchport mode fex-fabric
nexus(config-if)# channel-group 2 mode on
nexus(config-if)# interface port-channel 2
nexus(config-if)# fex associate 100

In this example, I created a port-channel with two interfaces and associated the fabric extender to the port-channel, providing link-level redundancy for the connection between the Nexus 2148 and the upstream Nexus 5010.

To verify that the fabric extender is coming online properly, you can use a few different commands. The show fex detail command produces some useful output (only the first several lines are included here):

FEX: 100 Description: FEX0100   state: Online
  FEX version: 4.2(1)N1(1) [Switch version: 4.2(1)N1(1)]
  FEX Interim version: 4.2(1)N1(1)
  Switch Interim version: 4.2(1)N1(1)
  Extender Model: N2K-C2148T-1GE, Extender Serial: JAF1321ANJN
  Part No: 73-12009-05
  Card Id: 70, Mac Addr: 00:0d:ec:cf:03:42, Num Macs: 64
  Module Sw Gen: 12594 [Switch Sw Gen: 21]
  post level: complete
pinning-mode: static Max-links: 1
  Fabric port for control traffic: Eth2/1
  Fabric interface state:
    Po2 - Interface Up. State: Active
    Eth2/1 - Interface Up. State: Active

And that’s really about it. Yes, there are more advanced configurations—I’m interested in exploring the use of virtual port-channels upstream of a Nexus 2000 series fabric extender to multiple Nexus 5000 switches—but this will get you started.

Feel free to post corrections, suggestions, or any other feedback in the comments!

Tags: , ,

SAN Port Channels from Nexus 5010 to MDS 9134

Tuesday, November 30, 2010 in Networking, Storage by slowe | 17 comments

As part of an ongoing effort to expand the functionality of the vSpecialist lab in the EMC RTP facility, we recently added a pair of Cisco MDS 9134 Fibre Channel switches. These Fibre Channel switches are connected to a pair of Cisco Nexus 5010 switches, which handle Unified Fabric connections from a collection of CNA-equipped servers. To connect the Nexus switches to the MDS switches, we used SAN port channels to bond multiple Fibre Channel interfaces together for both redundancy and increased aggregate throughput. Here is how to configure SAN port channels to connect a Cisco Nexus switch to a Cisco MDS switch.

If you are interested, more in-depth information can be found here on Cisco’s web site.

Although I’ve broken out the configuration for the MDS and the Nexus into separate sections, the commands are very similar. In my situation, the MDS 9134 was running NX-OS 5.0(1a) and the Nexus 5010 was running NX-OS 4.2(1)N1(1).

Configuring the Cisco MDS 9134

To configure the MDS 9134 with a SAN port channel, use the following commands.

First, create the SAN port channel with the interface port-channel command, like this:

mds(config)# interface port-channel 1

You can replace the “1″ at the end of that command with any number from 1 to 256; it’s just the numeric identifier for that SAN port channel. The SAN port channel number does not have to match on both ends.

Once you’ve created the SAN port channel, then add individual interfaces with the channel-group command:

mds(config)# interface fc1/16
mds(config-if)# channel-group 1

The “1″ specified in the channel-group command has to match the number specified in the earlier interface port-channel command. This might seem obvious, but I wanted to point it out nevertheless.

Repeat this process for each interface you want to add to the SAN port channel. In my example, I used two interfaces.

When you add an interface to the SAN port channel, NX-OS reminds you to perform a matching configuration on the switch at the other end, then use the no shutdown command to make the interfaces (and the SAN port channel) active. Let’s look first at the commands for configuring the Nexus, then we’ll examine what it looks like when we bring the SAN port channel online.

Configuring the Cisco Nexus 5010

The commands here are very similar to the MDS 9134. First, you need to create the SAN port channel using the interface san-port-channel command (note the slight difference in commands between the MDS and the Nexus here):

nexus(config)# interface san-port-channel 1

As with the MDS, the number at the end simply serves as a unique identifier for the SAN port channel and can range from 1 to 256.

Then add interfaces to the SAN port channel using the channel-group command:

nexus(config)# interface fc2/1
nexus(config-if)# channel-group 1
nexus(config-if)# interface fc2/2
nexus(config-if)# channel-group 1

As I’ve shown above, simply repeat the process for each interface you want to add to the SAN port channel. As on the MDS, NX-OS reminds you to perform a matching configuration on the opposite end of the link and then issue the no shutdown command.

Bringing Up the SAN Port Channel

Once a matching configuration is performed on both ends, then you can use the no shutdown command (which you can abbreviate to simply no shut) to activate the interfaces and the SAN port channel. After activating the interfaces, a show interface port-channel (on the MDS) or a show interface san-port-channel (on the Nexus) will show you the status of the SAN port channel. Only the first few lines of output are shown below (this output is taken from the Nexus):

nexus# sh int san-port-channel 1
san-port-channel 1 is trunking (Not all VSANs UP on the trunk)
    Hardware is Fibre Channel
    Port WWN is 24:01:00:05:9b:7b:0c:80
    Admin port mode is auto, trunk mode is on
    snmp link state traps are enabled
    Port mode is TE
    Port vsan is 1
    Speed is 4 Gbps
    Trunk vsans (admin allowed and active)  (1)
    Trunk vsans (up)                        ()
    Trunk vsans (isolated)                  ()
    Trunk vsans (initializing)              (1)

A couple of useful pieces of information are available here:

  • First, you can see that the SAN port channel is not fully up; it’s still initializing. This is shown by the “Not all VSANs UP on the trunk” message, as well as by the “Trunk vsans (initializing)” line.
  • Second, you can see the only a single member is up. Note the speed of the SAN port channel is listed as 4 Gbps.
  • Third, note that this is a trunking port, meaning that it could carry multiple VSANs. This is noted by the “Port mode is TE” line as well as the first line of the output (“san-port-channel 1 is trunking”).

As it turns out, I’d cabled the connections wrong; after I fixed the connections and gave the SAN port channel a small amount of time to initialize, the output was different (this output is taken from the MDS):

nexus# sh int port-channel 1
port-channel 1 is trunking
    Hardware is Fibre Channel
    Port WWN is 24:01:00:05:73:a7:72:00
    Admin port mode is auto, trunk mode is on
    snmp link state traps are enabled
    Port mode is TE
    Port vsan is 1
    Speed is 8 Gbps
    Trunk vsans (admin allowed and active)  (1)
    Trunk vsans (up)                        (1)
    Trunk vsans (isolated)                  ()
    Trunk vsans (initializing)              ()

Now you can see that both members of the SAN port channel are active (“Speed is 8 Gbps”) and that all VSANs are trunking across the SAN port channel.

At this point, you are now ready to proceed with creating VSANs, zones, and zonesets. Refer to these articles for more information on MDS zone creation and management via CLI:

New User’s Guide to Configuring Cisco MDS Zones via CLI
New User’s Guide to Managing Cisco MDS Zones via CLI

As always, questions, clarifications, or corrections are welcome—just add them below in the comments. Thanks!

Tags: , , , ,

Technology Short Take #2

Saturday, August 28, 2010 in Networking, Security, Storage, Virtualization by slowe | 4 comments

Welcome to Technology Short Take #2, a collection of links, thoughts, ideas, and items pertaining to data center technologies—virtualization, networking, storage, and security. I hope you find something useful or interesting!

  • The release of FLARE 30 and DART 6 by EMC (formally announced last week) introduces some new concepts and new functionality. Matt Hensley recently did a write-up on some of the new functionality in this post on virtual provisioning, storage pools, and FLARE 30. It’s worth a read if you aren’t already familiar with these technologies and need a primer.
  • If you are looking for the definitive guide on connectivity between various VMware vSphere components and the TCP/UDP ports required, you need only look here. Great information!
  • Here’s a great guide from Cisco on deployment options when deploying 10 Gigabit Ethernet on VMware vSphere 4.0 with the Nexus 1000V or the VMware vNetwork Distributed Switch. I’ve read through it, but I’ve added it to my list of documents to go back and study more carefully; there’s lots of useful information in here.
  • Way back in March Dave Convery posted this article on limitations with VMware vShield Zones. While re-reading that article today, I noted in the comments that the Nexus 1000V has a feature called Virtual Service Domains that help address some of the limitations of vShield Zones (at that time). As pointed out in the comments, this makes vShield Zones usable in two NIC scenarios such as with Cisco UCS. If anyone has any additional links on Virtual Service Domains, please share them in the comments. This is a topic that I think needs some additional attention.
  • This article is a good breakdown of the differences in storage identifiers between ESX 3.x and ESX 4.1.
  • Jeff Woolsey at Microsoft finally wraps up his series of articles on Hyper-V Dynamic Memory with Part 6. I’ve been reading this series pretty faithfully as Jeff systematically lays out the various ways in which memory is handled in a virtualization scenario, and I’ve been consistently struck by the impression that Jeff was working really hard to distinguish what Microsoft was doing with Hyper-V from what VMware does with ESX/ESXi. In the end, though, I can’t help but see all the similarities between the two. Dynamic Memory allocates additional memory to a VM as it needs it (much the same way ESX/ESXi does by allocating memory only as requested by the VM) and reclaims free pages from the VMs (just like ESX/ESXi reclaims idle pages via idle page reclamation). When under memory pressure, Hyper-V might force the guests to page out to disk; ESX/ESXi’s memory balloon driver achieves the same effect. What’s missing, obviously, is that with Hyper-V the hypervisor itself won’t swap pages out to disk (ESX/ESXi will do this under extreme circumstances). Am I missing something, or is Microsoft’s Dynamic Memory a lot more like VMware’s memory management technologies than Microsoft wants to admit? Feel free to enlighten me (courteously and with full disclosure) in the comments if I’m missing something.
  • Via Geert Verbist’s site, I found this article on application consistent quiescing via VMware’s VSS integration in VMware Tools. (For more information on VSS support within VMware Tools, check out my liveblog from Partner Exchange earlier this year.) This is good to hear, but what’s still not clear is whether the application consistent snapshots will truncate transaction logs. If anyone has more information, speak up in the comments.
  • I think I pointed this out a week or two ago on Twitter, but I thought I’d mention here at well. If you ever need to help decode which WWPNs map to which ports on an EMC CLARiiON array, this article is quite helpful. Anyone have matching articles for EMC Symmetrix, NetApp, HP, HDS, or other arrays?
  • With the formal announcement by VMware that vSphere 4.1 will be the last major release that includes ESX, ESXi is naturally getting much more attention. With that, there’s been a flurry of ESXi-related articles:
    Using vMA As Your ESXi Syslog Server
    The Migration From ESX to ESXi is Happening: Moving Configurations, Part 1
    The Migration from ESX to ESXi is Happening: Moving Configurations, Part II
    My VMware ESXi Installation Checklist
    Virtually Ghetto: ESXi 4.1 – Major Security Issue (also documented here in the VMware KB)
    ESXi 4.1 – Major Security Issue – The Sequel and the Workaround
    ESXi 4.1 Active Directory Integration
  • If you’re into Cisco UCS but like Hyper-V instead of VMware vSphere, Cisco has a white paper on Cisco UCS with Hyper-V for delivery of virtualized Exchange 2010.
  • I’m a command-line junkie, so I liked this article on how to put an ESX host into maintenance mode from the CLI.
  • For those seeking to get up to speed on the Nexus 7000 switches, “Fryguy” posted some training documents on his site. I haven’t read them (yet), but they’re on my list of documents to read (a list that grows ever longer…)

I guess that will do it for this time around. I hope that you’ve found something useful and, as always, feel free to add more useful links or tidbits in the comments. Thanks for reading!

Tags: , , , , , , , , ,

« Older entries