July 2009

You are currently browsing the monthly archive for July 2009.

Client-Specific DHCP Options with Linux DHCP Server

Tuesday, July 21, 2009 in Linux, Networking by slowe | 2 comments

Last week, I had a need to present a different set of DHCP options to one specific DHCP client (my iPhone) on my home network. Being the geek that I am, I have a small server set up here at the house running Ubuntu Linux. (You can read about the latest evolution of my home network in this article.) Now, I knew that this was possible using the Windows DHCP server, but I’d never done it with the Linux DHCP server. So, in case you find yourself in a similar situation, here’s how it works.

The Linux DHCP server configuration file (typically dhcpd.conf) is broken into different blocks. For example, the “main” portion of the configuration file might look something like this:

subnet 192.168.128.0 netmask 255.255.255.0 {
   option routers 192.168.128.1;
   range dynamic-bootp 192.168.128.50 192.168.128.150;:
   option domain-name-servers 208.67.222.222, 208.67.220.220; }

If you want to set up a reservation—so that a particular DHCP client always gets the same IP address—you set up additional blocks, like this:

host <hostname> {
   hardware ethernet 00:11:22:33:44:55;
   fixed-address 192.168.128.200; }

As it turns out, if you want to specify a different set of DHCP options to a client with a reservation (for example, in my situation I wanted to specify a different set of DNS servers), you just add a declaration to the client-specific section:

host <hostname> {
   hardware ethernet 00:11:22:33:44:55;
   fixed-address 192.168.128.200;
   option domain-name-servers 192.168.128.10; }

Of course, now that I know this it seems incredibly obvious. At the time that I was trying to figure this out, though, I wasn’t sure exactly what the syntax would look like. So, next time you find yourself needing to change the options on a DHCP reservation on Linux, you’ll know what to do!

Tags: ,

A Bit of an AppleScript Kick

Saturday, July 18, 2009 in Macintosh by slowe | No comments

I’ve been on a bit of an AppleScript kick recently. I’m not 100% sure exactly why, but I have. I’ve always been a bit of a fan of Apple’s “natural language” scripting engine, but I’ve also always been frustrated that more applications don’t support it. Even Apple’s own applications don’t support AppleScript as well as some other applications do.

In the event that you like using AppleScript, too, I thought I’d post my scripts here, along with a brief description of each one. You may need to modify them to suit your needs, and I’ll open deny any liability for anything that happens if you decide to use them. If you suddenly become more productive, it’s not my fault.

These scripts were written for use by/with the following applications, and all scripts (where applicable) offer support for notifications via Growl:

I wrote a couple of AppleScripts for Viscosity as well, but those are so ridiculously simple that I won’t even bother posting them. Just look at this link and you’ll see the extent of Viscosity’s AppleScript support.

Without any further delay, then, here are the scripts!

Send Headline to OmniFocus

Download Link

I think I got the basis for this script somewhere else, but honestly I can’t remember where. The idea behind this script is that when you see a headline in NetNewsWire that looks interesting, you invoke this script and it creates an action in OmniFocus for you. That way, you can quickly scan all the headlines in NetNewsWire, create OmniFocus actions for those that warrant further attention, and then get back to whatever it was you were doing previously. Like most—if not all—of the scripts here, I generally invoke this script using Quicksilver.

Send Tweet to OmniFocus

Download Link

This script was directly based on this blog entry, so I’m not due any of the credit. Once again, the idea is to support quick information aggregation. You see a tweet in Twitterrific that looks interesting, or perhaps it has a link in it that you want to investigate further. Invoke the script and it will add an action to OmniFocus with the contents of the tweet. Later, when it fits into your workflow, you can perform a more in-depth review of the information and process it appropriately.

Retweet Unmodified Post

Download Link

The current version of Twitterrific (version 3.2) lacks quite a bit of functionality, like retweeting, view the whole conversation, etc. So, to work around the lack of built-in retweet functionality, I wrote this script. It’s not the greatest in the world, but it helps a little bit. Select the tweet you want to retweet, invoke the script, and your Mac takes care of the rest.

Send URL to OmniFocus (Camino)

Download Link

You can probably guess the purpose behind this script: to take the information from the frontmost Camino window and create a task in OmniFocus. Yes, that’s right, I have very little imagination. I figure if you limit the amount of browsing you do to defined times (something I’m still working to perfect) then you can instead focus on more important things—you know, like getting your work done. Bosses like that. You only need to invoke the script and it will automatically pull the URL and the page title and push them into OmniFocus.

I also have a Safari version.

Send URL to Pukka (Camino)

Download Link

After mourning the loss of Cocoalicious for quite some time, I switched to Pukka. Pukka offers a built-in service accessible via the Services menu, but it wasn’t picking up enough information from the browser. So I wrote this script to retrieve the URL, page title, and selected text (if any) from the frontmost Camino window and feed them to Pukka. The user then adds any tags and posts the URL to Delicious.com.

Open Source in TextMate (Camino)

Download Link

This one was more challenging than I had anticipated. I suspected TextMate’s AppleScript support would be more than it was, which was—quite frankly—rather disappointing. In any case, invoke this script and the HTML source from the frontmost Camino browser window will be opened in TextMate.

Well, that’s it. If you have any useful AppleScript scripts, tips, tricks, or other trivia to share, please speak up in the comments.

Tags: ,

Mudslinging Between Cisco and HP

Thursday, July 16, 2009 in General, Networking, PASS by slowe | 25 comments

I’ll preface this article by saying that I am not (yet) an expert with Cisco’s Unified Computing System (UCS), so if I have incorrect information I’m certainly open to clarification. Some would also accuse me of being a UCS-hater, since I had the audacity to call UCS a blade server (the horror!). Truth is, I’m on the side of the customer, and as we all know there is no such thing as a “one size fits all” solution. Cisco can’t provide one, and HP can’t provide one.

The mudslinging that I’m talking about is taking place between Steve Chambers (formerly with VMware, now with Cisco) and HP. HP published a page with a list of reasons why Cisco UCS should be dismissed, and Steve responded on his personal blog. Here are the links to the pages in question:

The Real Story about Cisco’s “One Giant Switch” view of the Datacenter (this was based, in part at least, on the next link)
Buyer beware of the “one giant switch” data center network model
HP on the run

I thought I might take a few points from these differing perspectives and try to call out some mudslinging that’s occurring on both sides. To be fair, Steve states in the comments to his article that it was intended to be entertaining and light-hearted, so please keep that in mind.

Point #1: Complexity

The reality of these solutions is that they are both equally complex, just in different ways. HP’s BladeSystem Matrix uses reasonably well-understood and mature technologies, while Cisco UCS uses newer technologies that aren’t as widely understood. This is not a knock against either; as I’ve said before in many other contexts and many other situations, there are advantages and disadvantages to every approach. HP’s advantage is that leverages the knowledge and experience that people have with their existing technologies: StorageWorks storage solutions, ProLiant blades, ProCurve networking, and HP software. The disadvantage is that HP is still tied to the same “legacy” technologies.

In building UCS, Cisco’s advantage is that the solution uses the latest technologies (including some that are still Cisco-proprietary) and doesn’t have any ties to “legacy” technologies. The disadvantage, naturally, is that this technological leap creates additional perceived complexity because people have to learn the new technologies embedded within UCS.

Adding to the simple fact that both of these solutions are equally complex in different ways is the fact that you must re-architect your storage in order to gain the full advantage of either solution. To get the full benefit of both UCS and HP BladeSystem Matrix, you need to be doing boot-from-SAN. (Clearly, this doesn’t apply to virtualized systems, but both Cisco and HP are touting their solutions as equally applicable to non-virtualized workloads.) This is a fact that, in my opinion, has been significantly understated.

Neither HP nor Cisco really have the right to proclaim their solution is less complex than the other. Both solutions are complex in their own ways.

Point #2: Standards-Based vs. Proprietary

Again, neither HP nor Cisco really have any room to throw the rock labeled “Proprietary”. Both solutions have their own measure of vendor lock-in. HP is right; you can’t put an HP blade or an IBM blade into a Cisco UCS chassis. Steve Chambers is right; you can’t put a Dell blade or a Cisco blade server into an HP chassis. The reality, folks, is that every vendor’s solution is has a certain amount of vendor lock-in. Does VMware vSphere have vendor lock-in? Sure, but so does Hyper-V and Citrix XenServer. Does Microsoft Windows have vendor lock-in? Of course, but so does…so does…well, you get the idea.

HP says VNTag is proprietary and won’t even work with some of Cisco’s own switches. OK, let’s talk proprietary…does Flex-10 work with other vendor’s switches? The fact of the matter is that both Cisco and HP have their own forms of vendor lock-in and neither can cry “foul” on the other. It’s a draw.

Point #3: The “Giant Network Switch”

At one point in HP’s article (I believe it was under the Complexity heading) they make this point about the network traffic in a Cisco UCS environment:

In Cisco’s one-giant-switch model, all traffic must travel over a physical wire to a physical switch for every operation. Consequently, it appears that traffic even between two virtual servers running next to each other on the same physical would have to traverse the network, making an elaborate “hairpin turn” within the physical switch, only to traverse the network again before reaching the other virtual server on the same physical machine. Return traffic (or a “response” from the second virtual machine) would have to do the same. Each of these packet traversals logically accounts for multiple interrupts, data copies and delays for your multi-core processor.

I do have to call “partial FUD” on this one. In a virtualized environment, even a virtualized environment running the Cisco Nexus 1000V, traffic from one virtual server to another virtual server on the same host never leaves that host. HP’s statement seems to imply that’s not the case, and as far as I know it is. However, HP’s statement is partially true: traffic from one virtual server on one physical host does have to travel to the fabric interconnect and then back again in order to communicate with a virtual server running on a physical host in the same chassis. The fabric extenders don’t provide any switching functionality; that all occurs in the interconnect. Based on the information I’ve seen thus far, I would say that using Cisco’s SR-IOV-based “Palo” adapter and attaching VMs directly to a virtual PCIe NIC would put you into the situation HP is describing, which then just reinforces a question that Brad Hedlund and I tossed back and forth a couple of times: is hypervisor-bypass, aka VMDirectPath, with “Palo” the right design for all environments? In my opinion, no—I again go back to my statement that there is no “one size fits all” solution. And considering that the use of hypervisor-bypass with “Palo” would put you into a situation where traffic between two virtual machines on the same physical host has to travel to the fabric interconnect and back again, I’m even less inclined to use that architecture.

In the end, it’s pretty clear to me that both HP and Cisco have some advantages and disadvantages to their respective solutions, and neither vendor really has the room to label the other as “more complex” or “more proprietary” than the other. But what do you think? Do you agree or disagree? Courteous comments (with full vendor disclosure) are welcome.

Tags: , , , ,

VMware Releases a Trio of New Products

Monday, July 13, 2009 in Virtualization by slowe | No comments

Today VMware is releasing three new products in the vCenter line:

  • vCenter Lab Manager 4.0, the next major version of VMware’s very popular lab automation software;
  • vCenter AppSpeed; and
  • vCenter Chargeback.

vCenter Lab Manager 4.0 brings a few very significant features, not the least of which is full vSphere compatibility. Another major feature is cross-host VM fencing, which allows users to leverage Lab Manager’s fencing functionality—thus allowing multiple teams of networks to share the exact same TCP/IP configuration—while also taking advantage of VMotion and Distributed Resource Scheduler (DRS). This is a big one, as I’ve had multiple customers inquire about the interaction between Lab Manager and other features like DRS.

With the release of Lab Manager 4.0, VMware is also taking the step of integrating some products with overlapping functionality. I’ve had more than a few questions about the relationship between vCenter Lab Manager and vCenter Stage Manager. Apparently, that was a question lots of people had, and to answer that question VMware is now integrating Stage Manager and Lab Manager into a single product. This makes a lot of sense, in my opinion, and will definitely help strengthen the Lab Manager product.

Also being released today is vCenter AppSpeed, VMware’s performance management product. Based on the technology acquired from Beehive, AppSpeed aims to give VMware administrators the ability to “see” deeper into the environment than before. With that visibility, then, comes the ability to more accurately pinpoint current and potential performance bottlenecks, as well as the ability to prove end-user performance metrics. I’m sure you’ve run into this problem: you virtualize an application, and then an end user complains about performance. Using AppSpeed, VMware administrators can determine if the virtualization layer is what caused a performance impact, or if there is a performance impact at all.

Finally, vCenter Chargeback is the third product being released. Lots of customers talk about chargeback, but very few customers actually implement chargeback. VMware hopes to make chargeback easier with its new product, which allows customers to start with “show-back”, i.e., showing the business what it costs for each virtual machine being provisioned. This also has the (perhaps unintended) side effect of helping to curb VM sprawl, which is usually caused by a lack of understanding of the cost of resources within the virtualized environment.

For more information on any of these products, visit VMware’s web site. (As of the time I published this post, VMware’s web site had not yet been updated with the new information.)

Tags: ,

Follow-Up About Multiple VLANs, Virtual Connect, and Flex-10

Thursday, July 9, 2009 in Networking, Virtualization by slowe | 30 comments

I wanted to post a quick follow-up on the previous two articles that I published regarding using VLANs, Virtual Switch Tagging, HP Virtual Connect, and Flex-10:

Using VMware ESX Virtual Switch Tagging with HP Virtual Connect
Using Multiple VLANs with HP Virtual Connect Flex-10

One thing that I wanted to really clarify was that you can present multiple VLANs to FlexNICs on the same LOM, but you can’t present the same set of VLANs to FlexNICs on the same LOM. I’m not sure that I made that clear enough in my other post. So, if you have VLANs 100, 101, 102, 103, and 200, you can present any number or combination of those to all the FlexNICs on a single LOM—but it must be in a non-overlapping configuration, so that the same VLAN isn’t presented to multiple FlexNICs on the same LOM. I plan on posting some sample configurations, with graphics, that should clarify things even more.

The other thing I wanted to clarify was why I posted an article about presenting multiple VLANs to FlexNICs on the same LOM. Usually, this topic comes up in the form of a question (and I’ve had several readers e-mail me about this) like this: “You state that you can’t present the same set of VLANs to multiple FlexNICs on the same LOM. Why in the world would you want to do that?”

That’s a good question! In a Flex-10 environment, you normally wouldn’t want to do that, and not just for the reason that it doesn’t work (although having a configuration that works is usually quite beneficial). Consider the value proposition behind Flex-10: it provides four logical NICs (the FlexNICs), each of whose bandwidth can be adjusted as needed, up to 10Gbps, based on the traffic requirements. Now consider the reason why administrators normally use multiple NICs: more bandwidth. Considering that you can allocate bandwidth easily with a FlexNIC, there’s no need to use multiple FlexNICs on the same LOM to handle the same VLANs. A single FlexNIC can handle multiple VLANs just fine because you can allocate more bandwidth to that FlexNIC easily. And since presenting multiple VLANs to FlexNICs on different LOMs works just fine, you can use one FlexNIC from each LOM to gain redundancy. All the reasons for wanting to use multiple NICs are addressed by using only two FlexNICs, one from each LOM, and presenting as many VLANs as you like to those two FlexNICs.

However, having said all that, it is the default configuration in many VMware environments to present VLAN trunks to all ports on all ESX/ESXi hosts (i.e., to present the same set of VLANs to all ports). In a Flex-10 environment, you’ll have to break out of that line of thinking. Hence, why I posted the information that I posted, so that VMware administrators would realize they can’t follow the same configuration guidelines in the Flex-10 environment as they would follow in a more “traditional” networking environment. Just as virtualization with VMware requires server admins to approach things differently, the functionality offered by Virtual Connect also requires server admins to think a bit differently about how network connectivity is presented to VMware ESX/ESXi hosts.

Have more questions, or need additional clarification? Speak up in the comments. Thanks for reading!

Tags: , , ,

Using Multiple VLANs with HP Virtual Connect Flex-10

Thursday, July 9, 2009 in Networking by slowe | 22 comments

In this article on using VMware ESX Virtual Switch Tagging (VST) with HP Virtual Connect, I showed you how to use the Multiple VLANs setting to map multiple VLANs onto a network connection so that the VLAN tags would pass all the way up to the VMware ESX/ESXi host—a necessary prerequisite for making VST work.

However, there is a key caveat to this approach that applies when using HP Virtual Connect Flex-10 and HP blades that have Flex-10 LOM (LAN on Motherboard) interfaces. As you might already know, Flex-10 LOMs have the ability to “subdivide” themselves into four logical instances, each of them a valid PCIe function, which are called FlexNICs. These FlexNICs appear as real, actual, physical NICs to the operating system installed on the blades. This includes VMware ESX/ESXi. In the Virtual Connect Manager, though, you have the ability to fine-tune the amount of bandwidth allocated to each of these FlexNICs, up to the shared maximum of 10Gbps.

This is pretty cool, but there is one limitation of which you must be aware—a limitation that is particularly significant in VMware ESX/ESXi environments. When you use the Multiple Networks option to map multiple VLANs onto a FlexNIC, you can’t map the same VLAN onto two different FlexNICs from the same LOM.

The FlexNICs are noted as LOM 1:a, LOM 1:b, LOM 2:a, etc. Again, as noted earlier, up to four FlexNICs are presented to the operating system on the blade. When you start assigning network connections in a Server Profile in Virtual Connect Manager, these network connections will bounce back and forth between the LOMs (assuming there are no other network interface cards in the server blade):

First network connection > LOM 1:a
Second network connection > LOM 2:a
Third network connection > LOM 1:b
Fourth network connection > LOM 2:b
…
Seventh network connection > LOM 1:d
Eighth network connection > LOM 2:d

As far as I know, there is no way to change this behavior.

With that in mind, what this means is that you can’t map the same VLANs to the first, third, fifth, and seventh network connections, or to the second, fourth, sixth, or eighth network connections. Why? Because each of these connections are logical FlexNICs on the same LOM, and you can’t map the same VLANs to more than one FlexNIC on the same LOM.

Perhaps an example would help. Consider the configuration shown in this figure, in which multiple VLANs are mapped to all eight connections in Virtual Connect Manager:

hp-flex10-vlans-incorrect.png

This screenshot shows how the VLANs are mapped for each of those eight network connections:

hp-flex10-vlan-mapping.png

As you can see, I have the same set of five VLANs mapped onto all eight network connections (all eight logical FlexNIC instances). But only the first two show OK—the rest show Critical. Why? Because these logical FlexNICs have the same VLANs mapped to them as were mapped to the first FlexNIC, and therefore Virtual Connect Manager has placed them into a Critical state (they’ll be reported as “Down” to an operating system on the blade).

This behavior is the strange behavior I tweeted about a few days ago, where I couldn’t figure out why Virtual Connect was behaving in the way that it was. Now I know why!

Contrast that first configuration with the configuration shown in this screenshot:

hp-flex10-vlans-correct.png

In this case, you’ll note that I do not have the same VLANs mapped to more than one FlexNIC on the same LOM. As a result, Virtual Connect Manager does not place any of the FlexNICs into a Critical state, and all eight show OK (and will be reported as Up to an operating system on the blade).

So what does this mean? In its simplest terms, it means you can’t use VST on all the FlexNICs—some of the FlexNICs will have to carry “ordinary” traffic to VMware ESX/ESXi port groups that have no VLAN ID specified. In the image above, you can see that the first three pairs of FlexNICs each carry a specific type of traffic. The matching output of esxcfg-vswitch --list for this VMware ESX host shows that the port groups on each of the three matching vSwitches do not have any VLAN IDs specified. This is because, in this configuration, these three pairs of FlexNICs carry only a single type of traffic, and that single type of traffic has no VLAN tags attached. Therefore, the VMware ESX/ESXi port groups must not have a VLAN ID specified in order for traffic to flow.

But it also presents some other interesting design considerations. If your VMware ESX Service Console (or VMware ESXi Management interface) is on the same VLAN as some of your virtual machines, you’ll run into an issue—you won’t be able to map the VLAN to one set of FlexNICs for Service Console traffic and then map that same VLAN to another set of FlexNICs for other virtual machine traffic. In effect, it greatly reduces the extent to which you can use VST on VMware ESX/ESXi hosts.

Of course, the other way of handling it is to assign only two network connections, map multiple VLANs to those network connections, assign the full 10Gbps of throughput to those two FlexNICs (network connections), and use a single vSwitch design.

As far as I can tell, this is not documented by HP in the Virtual Connect (or Flex-10) documentation. So, you might want to bookmark this article, or post it to Delicious.com or similar. Finally, as always, I’d love to hear any feedback or clarifications in the comments. Thanks!

Tags: , , ,

Submit a Question for VMworld 2009 Ask the Experts Session

Tuesday, July 7, 2009 in Virtualization by slowe | No comments

As many of you probably already know, I’ll be participating in an Ask The Experts session at VMworld 2009 in San Francisco, CA, this year. Together with Rick Scherer (of VMwareTips.com), Chad Sakac (Virtual Geek), Tom Howarth (PlanetVM), and Duncan Epping (Yellow Bricks), we’ll be taking questions on virtualization design.

If you have a question you’d like to see addressed during the session, here’s your opportunity to submit your question in advance! Use the form below to submit questions to be considered for inclusion in the Ask The Experts session. The panel will select a small number of questions that will be addressed during the session at VMworld 2009, along with questions submitted by the audience during the session.

Thanks, and I look forward to seeing many of you in San Francisco later this year!

Update as of 8/14/2009: Sorry, the call for questions for TA2259 has closed. However, if you are attending VMworld 2009, please feel free to join us in person. The session is running at 1PM and again at 4:30PM on Thursday, September 3.

Tags: , ,

Altor Announces VMsafe-Integrated Altor VF 3.0

Tuesday, July 7, 2009 in Security, Virtualization by slowe | No comments

Since the announcement of the VMsafe APIs at VMworld Europe 2008, the virtualization world has been waiting. First, we waited for the actual release of the VMsafe APIs, which came with the release of VMware vSphere 4. Next, we waited for the delivery of the first VMsafe-integrated security solutions. While I can’t say definitively that it’s the first, Altor Networks is announcing its VMsafe-integrated virtual firewall solution, Altor VF 3.0. The wait is over, and now we get to see: just how powerful does VMsafe allow virtual security solutions to be?

Only time will provide the full picture, but an initial glance at Altor’s press release and a pre-release discussion I had with Altor lead me to believe that VMsafe really will change the landscape of security solutions in VMware environments. By leveraging VMsafe in fast-path mode—meaning that the security solution runs as a module in the hypervisor—Altor is able to provide not only firewalling functionality but also intrusion detection functionality as well. In fact, the intrusion detection features can be configured to work only on traffic that successfully passes through the firewall rules.

Altor also claims much greater performance with Altor VF 3.0, up to ten times the performance of a virtual machine-based security solution. And, of course, Altor has ensured that their virtual firewall product can apply firewall rules at various levels within the VMware vCenter Server hierarchy, and the product also helps protect the hypervisor management interfaces as well (the Service Console interfaces in ESX, Management interfaces in ESXi).

The initial release of Altor VF 3.0 will use a separate web-based management console, but Altor Networks did indicate that they are investigating the use of a plug-in for the vSphere Client for more integrated management. Future versions of Altor VF also plan to address vApp integration, something that is missing from the initial release.

For more detailed information or for the full press release, visit Altor Networks’ web site.

Tags: , ,

Using VMware ESX Virtual Switch Tagging with HP Virtual Connect

Monday, July 6, 2009 in Networking, Virtualization by slowe | 18 comments

In January 2008, SearchVMware.com published an article of mine titled VMware ESX Server Networking with HP Virtual Connect. In that article, I stated that one drawback of HP Virtual Connect was that it forced you to use External Switch Tagging (EST):

When used in conjunction with ESX Server, shared uplink sets force the use of EST because VLAN tags are stripped away by the Virtual Connect switch. Therefore, the ESX Server can’t use the VLAN tags, and must resort to a different vSwitch—each with one or more pNICs as uplinks—for each VLAN/associated network. This solution may be useful in some situations, but typically wouldn’t scale well for environments with many different VLANs.

It turns out that a firmware revision to the HP Virtual Connect software addresses this problem. As I’ve recently had the opportunity to work with an HP Virtual Connect Flex-10 module (you can expect to see some articles on Flex-10 in the near future), I wanted to revisit the idea of using HP Virtual Connect with VMware ESX/ESXi. In this post, I’ll describe how you go about configuring HP Virtual Connect so that you can use Virtual Switch Tagging (VST) and Shared Uplink Sets together. Each of the steps is described in one of the sections below.

Configure VC for VLAN Mapping

Before you even create the Shared Uplink Set, you must first configure the Virtual Connect module to use VLAN mapping instead of VLAN tunneling.

To access the option for configuring VLAN mapping, you can use the menu bar across the top of the right side of the HP Virtual Connect Manager. Simply click Configure > Ethernet Settings, then click on the Advanced Settings tab. There you will see the option to either tunnel VLAN tags or map VLAN tags. Choose to map VLAN tags. Optionally, you can click the check box to force server connections to use the same VLAN mappings; this will eliminate a step later but limits the overall flexibility of the solution. It’s up to you if you want to use this option.

Create the Shared Uplink Set

Now you’re ready to create the Shared Uplink Set. Using the menu bar across the top of the right side of the HP Virtual Connect Manager interface, simply choose Define > Shared Uplink Set. Specify a name for the uplink set, then choose the external uplink ports. While you here, you can also go ahead and create the associated networks you’ll need later.

Create the Associated Networks

Either while you’re creating the Shared Uplink Set or after the Shared Uplink Set has been created, you can add the Associated Networks. While you are editing the Shared Uplink Set, simply click the Add Network button under the Associated Networks area and define one or more VLANs. The following parameters are available when you define an Associated Network:

  • Network Name and VLAN ID: These are pretty self-explanatory. The VLAN ID here needs to match the external VLAN ID on the rest of the network.
  • Native: If this VLAN is marked as the native VLAN on the rest of your network, check this box. This network would then receive all of the untagged traffic on the uplink set.
  • Smart Link: If you would like this network to be marked as down if the uplinks go down, check this box.
  • Private network: With this box checked, the network will act like a private VLAN–nodes on this network cannot communicate with each other.
  • Advanced: This area allows you to set a custom speed for either the preferred speed or the maximum speed.

After you’ve defined the Associated Networks, then you’re ready to create the Server Profile—and that’s where the real magic in making VST is found.

Assign Networks in the Server Profile

Once again, you’ll use the menu bar across the right side of the HP Virtual Connect Manager to create a Server Profile. Simply select Define > Server Profile. In the Server Profile, you’ll add a network for each NIC present in the server blade (for a blade with Flex-10 NICs and a Flex-10 module, you will have eight NICs). When prompted for what network to associate to that NIC, choose Multiple Networks. Then click the small Edit button just to the right of the Network Name drop-down to show the Server VLAN to vNet Mappings screen.

The fact that you selected “Multiple Networks” when you added the connection to the Server Profile means that Virtual Connect will pass the VLAN tags up to the blade. The fact that you configured the Virtual Connect module to use VLAN mapping now means that you can create an association between the VLAN tags that a server uses and an corresponding Associated Network.

If you want to keep the server’s VLAN tags and the Associated Networks’ VLAN IDs matched up, just follow these steps:

  1. Check the box labeled Force Same VLAN Mappings As Shared Uplink Sets.
  2. Choose the Shared Uplink Set from the drop-down list.
  3. Place a check mark next to each Associated Network/vNet/VLAN. This tell the Virtual Connect module to include that VLAN.
  4. Place a check mark under Untagged for whichever Associated Network is should be handled as the untagged (native) VLAN.

If, on the other hand, you want to specify different server VLAN tags than Associated Network/vNet VLAN IDs, leave the check box for Force Same VLAN Mappings As Shared Uplink Sets unchecked, and specify the server VLAN ID that should be used for each Associated Network/vNet. For example, if the server was using VLAN ID 10 to refer to the Production network, but the Production network was using VLAN 1000 on the Associated Network and on the rest of the network, then choose the Associated Network that represents the Production network and specify a server VLAN ID of 10. This allows you to create a mapping between the VLAN tags the server uses and the VLAN tags the rest of the network uses.

After you’ve defined the Server Profile and created the vNet mappings, attach the Server Profile to a blade running VMware ESX/ESXi and you’re good to go! Within VMware ESX/ESXi, you would configure the vSwitches, distributed vSwitches, and port groups as you would normally.

How I Tested

My testing was performed on a HP Virtual Connect Flex-10 module running firmware revision 2.10. The Flex-10 module was uplinked via a single 10Gbps connection to an HP ProCurve switch. The blades were running VMware ESX 4.0.0.

Tags: , , , , ,

Another Reason Not to Use PVSCSI or VMXNET3

Sunday, July 5, 2009 in PASS, Virtualization by slowe | 20 comments

You might have read the article I wrote here titled vSphere Virtual Machine Upgrade Process, in which I described a process whereby you could upgrade your VMs to VM hardware version 7 (the version used with vSphere) as well as use the latest paravirtualized network and SCSI drivers (VMXNET3 and PVSCSI). Both PVSCSI and VMXNET3 offer greater performance with the same CPU utilization.

Rightfully so, some readers and other bloggers pointed out that PVSCSI isn’t supported for boot disks (Rich Brambley put up a really good post, for example). Rich, among others, suggested moving virtual machines back to a “two disk model,” with a boot disk and a separate data disk; this would allow for the greater performance of the PVSCSI controller on the data disk. This seemed to be a reasonable workaround. I don’t recall hearing about any significant issues with VMXNET3. Using the newer network driver seemed to be a good move all the way around.

Unfortunately, there is another drawback to both of these devices. Rich caught this drawback in his article, but relegated it to a small mention at the very end of the article that even I overlooked at first (emphasis mine):

There are some other factors to consider as well. For example, vSphere Fault Tolerance cannot be enabled on a VM using PVSCSI.

That’s right—you cannot use VMware Fault Tolerance (FT) on a virtual machine that is using the PVSCSI device. However, this restriction doesn’t just apply to the PVSCSI device; it also applies to VMXNET3! VMware FT cannot be enabled on a virtual machine using either the VMXNET3 or PVSCSI devices; vCenter Server will simply report an error that the network interface or disk controller isn’t supported for VMware FT.

In my opinion, this is a significant enough limitation that I felt it warrants its own post. If you are planning on using VMware FT in your environment, be sure not to configure any virtual machines to use VMXNET3 or PVSCSI if they might need to be protected with VMware FT. In this case, you’ll have to choose from either maximum performance or maximum protection—you don’t get both.

UPDATE: Rich Brambley shared links to two resources that describe the incompatibility between VMware FT and PVSCSI and VMXNET3:

VMware Communities: Unable to configure FT with error “Unsupported virtual machine configuration for Fault Tolerance. Device ‘Network adapter 1′ is not supported”
VMware Fault Tolerance Requirements and Limitations

Tags: , , ,

« Older entries § Newer entries »