ESX

You are currently browsing articles tagged ESX.

VMware has completed Microsoft Server Virtualization Validation Program (SVVP) certifications for both VMware vSphere 4.0 as well as ESX/ESXi 3.5 Update 4. This brings the list of SVVP-certified products to include:

  • VMware vSphere 4.0 (ESX 4.0 and ESXi 4.0)
  • VMware ESX 3.5 Update 4
  • VMware ESXi 3.5 Update 4
  • VMware ESX 3.5 Update 3
  • VMware ESXi 3.5 Update 3
  • VMware ESX 3.5 Update 2

According to my contacts within VMware—and many of you have probably heard the same—the company is seeking to achieve SVVP certification for every ESX and ESXi release from 3.5 Update 2 onward for the maximum supported configuration of both CPUs and RAM on both Intel and AMD platforms. That includes both 32-bit and 64-bit versions of Windows Server.

You can view the full list of SVVP-certified platforms here.

Tags: , , , ,

A lot of the content on this site is oriented toward VMware ESX/ESXi users who have a pretty fair amount of experience. As I was working with some customers today, though, I realized that there really isn’t much content on this site for new users. That’s about to change. As the first in a series of posts, here’s some new user information on creating vSwitches and port groups in VMware ESX using the command-line interface (CLI).

For new users who are seeking a thorough explanation of how VMware ESX networking functions, I’ll recommend a series of articles by Ken Cline titled The Great vSwitch Debate. Ken goes into a great level of detail. Go read that, then you can come back here.

Before I get started it’s important to understand that, for the most part, the information in this article applies only to VMware ESX. VMware ESXi doesn’t have a Linux-based Service Console like VMware ESX, and therefore doesn’t have a readily-accessible CLI from which to run these sorts of commands. There is a remote CLI available, which I’ll discuss in a future post, but for now I’ll focus only on VMware ESX.

The majority of all the networking configuration you will need to perform on VMware ESX boils down to just a couple commands:

  • esxcfg-vswitch: You will use this command to manipulate virtual switches (vSwitches) and port groups.
  • esxcfg-nics: You will use this command to view (and potentially manipulate) the physical network interface cards (NICs) in the VMware ESX host.

Configuring VMware ESX networking boils down to a couple basic tasks:

  1. Creating, configuring, and deleting vSwitches
  2. Creating, configuring, and deleting port groups

I’ll start with creating, configuring, and deleting vSwitches.

Creating, Configuring, and Deleting vSwitches

You’ll primarily use the esxcfg-vswitch command for the majority of these tasks. Unless I specifically indicate otherwise, all the commands, parameters, and arguments are case-sensitive.

To create a vSwitch, use this command:

esxcfg-vswitch -a <vSwitch Name>

To link a physical NIC to a vSwitch—which is necessary in order for the vSwitch to pass traffic onto the physical network or to receive traffic from the physical network—use this command:

esxcfg-vswitch -L <Physical NIC> <vSwitch Name>

In the event you don’t have information on the physical NICs, you can use this command to list the physical NICs:

esxcfg-nics -l (lowercase L)

Conversely, if you need to unlink (remove) a physical NIC from a vSwitch, use this command:

esxcfg-vswitch -U <Physical NIC> <vSwitch Name>

To change the Maximum Transmission Unit (MTU) size on a vSwitch, use this command:

esxcfg-vswitch -m <MTU size> <vSwitch Name>

To delete a vSwitch, use this command:

esxcfg-vswitch -d <vSwitch Name>

Creating, Configuring, and Deleting Port Groups

As with virtual switches, the esxcfg-vswitch is the command you will use to work with port groups. Once again, unless I specifically indicate otherwise, all the commands, parameters, and arguments are case-sensitive.

To create a port group, use this command:

esxcfg-vswitch -A <Port Group Name> <vSwitch Name>

To set the VLAN ID for a port group, use this command:

esxcfg-vswitch -v <VLAN ID> -p <Port Group Name> <vSwitch Name>

To delete a port group, use this command:

esxcfg-vswitch -D <Port Group Name> <vSwitch Name>

To view the current list of vSwitches, port groups, and uplinks, use this command:

esxcfg-vswitch -l (lowercase L)

There are more networking-related tasks that you can perform from the CLI, but for a new user these commands should handle the lion’s share of all the networking configuration. Good luck!

Tags: , , , ,

It would appear (I have not yet been able to reliably verify this information) that VMware has removed support for the Adaptec aacraid driver from VMware vSphere. The driver was apparently listed on the Hardware Compatibility List (HCL) as supported at release, but shortly after release support was pulled. Apparently the aacraid driver is in such bad shape with vSphere that you can’t even install vSphere on systems using the aacraid driver. Even more mysterious is the fact that there is no documentation about this issue one way or the other, so it’s quite difficult to really verify where support stands. As of the last time I checked (a couple of days ago), the aacraid driver was still not listed on the HCL.

This primarily impacts white-box owners; users of systems from major vendors like HP, IBM, and Dell will most likely not be affected.

If anyone has any additional information on this matter, please speak up in the comments.

Tags: , , , , ,

Over the next couple of weeks, I’ll start posting a multi-part review of VMware vSphere 4.

Because this is such a large product with so many different features, I’ve decided to break it into three or four sections. As the different parts go live on the site, the list below will be modified to link to the appropriate part of the review:

  1. Overview and installation
  2. Networking and storage
  3. High availability and business continuity
  4. Management and operations
  5. Summary and wrap-up

If there is anything in particular you’d like to see covered in the review, please note your interests by posting a comment to this article. I’ll do my best to accommodate all requests, but I can’t make any guarantees.

Tags: , , , ,

In April 2008, I wrote an article on how to use jumbo frames with VMware ESX and IP-based storage (NFS or iSCSI). It’s been a pretty popular post, ranking right up there with the ever-popular article on VMware ESX, NIC teaming, and VLAN trunks.

Since I started working with VMware vSphere (now officially available as of 5/21/2009), I have been evaluating how to replicate the same sort of setup using ESX/ESXi 4.0. For the most part, the configuration of VMkernel ports to use jumbo frames on ESX/ESXi 4.0 is much the same as with previous versions of ESX and ESXi, with one significant exception: the vNetwork Distributed Switch (vDS, what I’ll call a dvSwitch). After a fair amount of testing, I’m pleased to present some instructions on how to configure VMkernel ports for jumbo frames on a dvSwitch.

How I Tested

The lab configuration for this testing was pretty straightforward:

  • For the physical server hardware, I used a group of HP ProLiant DL385 G2 servers with dual-core AMD Opteron processors and a quad-port PCIe Intel Gigabit Ethernet NIC.
  • All the HP ProLiant DL385 G2 servers were running the GA builds of ESX 4.0, managed by a separate physical server running the GA build of vCenter Server.
  • The ESX servers participated in a DRS/HA cluster and a single dvSwitch. The dvSwitch was configured for 4 uplinks. All other settings on the dvSwitch were left at the defaults.
  • For the physical switch infrastructure, I used a Cisco Catalyst 3560G running Cisco IOS version 12.2(25)SEB4.
  • For the storage system, I used an older NetApp FAS940. The FAS940 was running Data ONTAP 7.2.4.

Keep in mind that these procedures or commands may be different in your environment, so plan accordingly.

Physical Network Configuration

Refer back to my first article on jumbo frames to review the Cisco IOS commands for configuring the physical switch to support jumbo frames. Once the physical switch is ready to support jumbo frames, you can proceed with configuring the virtual environment.

Virtual Network Configuration

The virtual network configuration consists of several steps. First, you must configure the dvSwitch to support jumbo frames by increasing the MTU. Second, you must create a distributed virtual port group (dvPort group) on the dvSwitch. Finally, you must create the VMkernel ports with the correct MTU. Each of these steps is explained in more detail below.

Setting the MTU on the dvSwitch

Setting the MTU on the dvSwitch is pretty straightforward:

  1. In the vSphere Client, navigate to the Networking inventory view (select View > Inventory > Networking from the menu).
  2. Right-click on the dvSwitch and select Edit Settings.
  3. From the Properties tab, select Advanced.
  4. Set the MTU to 9000.
  5. Click OK.

That’s it! Now, if only the rest of the process was this easy…

By the way, this same area is also where you can enable Cisco Discovery Protocol support for the dvSwitch, as I pointed out in this recent article.

Creating the dvPort Group

Like setting the MTU on the dvSwitch, this process is pretty straightforward and easily accomplished using the vSphere Client:

  1. In the vSphere Client, navigate to the Networking inventory view (select View > Inventory > Networking from the menu).
  2. Right-click on the dvSwitch and select New Port Group.
  3. Set the name of the new dvPort group.
  4. Set the number of ports for the new dvPort group.
  5. In the vast majority of instances, you’ll want to set VLAN Type to VLAN and then set the VLAN ID accordingly. (This is the same as setting the VLAN ID for a port group on a vSwitch.)
  6. Click Next.
  7. Click Finish.

See? I told you it was pretty straightforward. Now on to the final step which, unfortunately, won’t be quite so straightforward or easy.

Creating a VMkernel Port With Jumbo Frames

Now things get a bit more interesting. As of the GA code, the vSphere Client UI still does not expose an MTU setting for VMkernel ports, so we are still relegated to using the esxcfg-vswitch command (or the vicfg-vswitch command in the vSphere Management Assistant—or vMA—if you are using ESXi). The wrinkle comes in the fact that we want to create a VMkernel port attached to a dvPort ID, which is a bit more complicated than simply creating a VMkernel port attached to a local vSwitch.

Disclaimer: There may be an easier way than the process I describe here. If there is, please feel free to post it in the comments or shoot me an e-mail.

First, you’ll need to prepare yourself. Open the vSphere Client and navigate to the Hosts and Clusters inventory view. At the same time, open an SSH session to one of the hosts you’ll be configuring, and use “su -” to assume root privileges. (You’re not logging in remotely as root, are you?) If you are using ESXi, then obviously you’d want to open a session to your vMA and be prepared to run the commands there. I’ll assume you’re working with ESX.

This is a two-step process. You’ll need to repeat this process for each VMkernel port that you want to create with jumbo frame support.

Here are the steps to create a jumbo frames-enabled VMkernel port:

  1. Select the host and and go the Configuration tab.
  2. Select Networking and change the view to Distributed Virtual Switch.
  3. Click the Manage Virtual Adapters link.
  4. In the Manage Virtual Adapters dialog box, click the Add link.
  5. Select New Virtual Adapter, then click Next.
  6. Select VMkernel, then click Next.
  7. Select the appropriate port group, then click Next.
  8. Provide the appropriate IP addressing information and click Next when you are finished.
  9. Click Finish. This returns you to the Manage Virtual Adapters dialog box.

From this point on you’ll go the rest of the way from the command line. However, leave the Manage Virtual Adapters dialog box open and the vSphere Client running.

To finish the process from the command line:

  1. Type the following command (that’s a lowercase L) to show the current virtual switching configuration:
    esxcfg-vswitch -l
    At the bottom of the listing you will see the dvPort IDs listed. Make a note of the dvPort ID for the VMkernel port you just created using the vSphere Client. It will be a larger number, like 266 or 139.
  2. Delete the VMkernel port you just created:
    esxcfg-vmknic -d <dvPort ID>
  3. Recreate the VMkernel port and attach it to the very same dvPort ID:
    esxcfg-vmknic -a -i <IP addr> -n <Mask> -m 9000 <dvPort ID>
  4. Use the esxcfg-vswitch command again to verify that a new VMkernel port has been created and attached to the same dvPort ID as the original VMkernel port.

At this point, you can go back into the vSphere Client and enable the VMkernel port for VMotion or FT logging. I’ve tested jumbo frames using VMotion and everything is fine; I haven’t tested FT logging with jumbo frames as I don’t have FT-compatible CPUs. (Anyone care to donate some?)

As I mentioned in yesterday’s Twitter post, I haven’t conducted any objective performance tests yet, so don’t ask. I can say that NFS feels faster with jumbo frames than without, but that’s purely subjective.

Let me know if you have any questions or if anyone finds a faster or easier way to accomplish this task.

Tags: , , , , , , , , ,

The news has hit the Internet in various places, but I wanted to point it out here because it does help to debunk the myth that virtualization can’t handle all workload. What’s the news? EMC and VMware have jointly demonstrated that a single VMware vSphere host running just three virtual machines can drive just above 350,000 I/O operations per second (IOPS).

I’ll let that sink in for just a moment. In case you don’t understand just how significant that number is, consider that a typical Fibre Channel drive can sustain somewhere just below 200 IOPS (and that’s being a bit generous). At 200 IOPS per drive, driving 350,000 IOPS would require 1,750 drives. (Fortunately, EMC used Enterprise Flash Drives (EFDs), so far fewer drives were required.) I would wonder how many of us have actually seen a storage array with that many drives.

Chad Sakac of EMC covered the tests on his blog here; the VMware Performance blog also discussed the results in detail as well.

So, next time you are thinking that VMware vSphere can’t handle your database workloads, keep these figures in mind. Or, if you’re a consultant like me, use these figures next time your customer says that virtualization can’t handle I/O-intensive workloads. This looks like pretty definitive results to me.

Tags: , , , , , ,

The fine folks over at Hyper9 recently offered me a very limited number of special beta invitations for Hyper9’s new Virtualization Mobile Manager (VMM) product. As you may already know, VMM is the brainchild of Andrew Kutz, who recently joined Hyper9 and has already released a few snippets of code via H9Labs.

Here are some highlights of VMM:

  • Supports all major hypervisors: VMware Server 2, VMware Infrastructure 3 (VMware ESX and VMware ESXi 3.5, VirtualCenter 2.5), Microsoft Hyper-V, and Citrix XenServer 5
  • Runs as an Apache Tomcat web application, supported on Windows, Linux, and Mac OS X
  • Accessible from just about any mobile device: Apple iPhone, Blackberry, Google Android-based phones, and Windows Mobile devices
  • “Gracefully degrades” into Lite Mode if the mobile device doesn’t support all the web UI features

While the VMM beta is open to the general public, I have 15 special invitations that will grant additional benefits (extra perks, if you will). Specifically, these beta invitations will come with:

  • A 50% discount on the already low pricing for VMM once it is released
  • Automatic entry into a contest, starting in June, to win a mobile device
  • A limited edition Hyper9 T-shirt (assuming you provide a little feedback to the team at Hyper9)

Interested in one of these special invitations? Well, you’re going to have to work for it. Post a comment to this article telling me why you should be one of the lucky 15 readers who gets a special invitation. Telling me you’ll help promote my upcoming vSphere book might improve your chances…or it might not! I’ll leave comments open until Friday, May 22, or until I get 30 comments on the article, whichever comes first. From the comments on the article I’ll select the top 15 to receive the special invitation to the VMM beta.

In the event you aren’t interested in one of the special invitations, or if you read this article after the invitations have already been given out, you can also register for the beta from the Hyper9 community site.

So post your comment now!

Tags: , , , , , , ,

I’m a bit behind the times on this one, as I know that several other bloggers have already made the announcement about the HyTrust Appliance Community Edition. This is a free version of the HyTrust Appliance that supports up to 3 ESX hosts and provides centralized access management and audit logging.

In any case, if you want more information on the HyTrust Appliance Community Edition, go have a look here at the HyTrust web site. If you are so inclined, you can get the full press release here.

Tags: , , ,

Today Double-Take Software announces their new Workload Optimization Suite. All of Double-Take’s flagship software products are now organized and unified within the idea of workload optimization, and new products are being announced to help provide a more complete set of solutions.

The products in the Workload Optimization Suite include:

  • Double-Take Move
  • Double-Take Flex
  • Double-Take Backup
  • Double-Take Availability

Of these four products, two of them—Move and Flex—are new products also being announced today. These new products are available today. Double-Take Backup and Double-Take Availability are available under existing Double-Take, Livewire, TimeData, and GeoCluster brands. For example, Double-Take for Windows will fold into the Double-Take Availability and Double-Take Backup products later this year with an update.

Double-Take Move is one of the new products that was announced today. Double-Take Move leverages Double-Take’s existing replication technologies to provide a platform-independent X2X migration engine. X2X means any-to-any: physical-to-virtual (P2V), physical-to-physical (P2P), virtual-to-physical (V2P), and virtual-to-virtual (V2V) are all supported. In addition, Double-Take Move will automatically create a VMware ESX or Microsoft Hyper-V virtual machine when the destination is a virtual machine. Pricing is available per-use or for an entire site. Personally, I’ve never been a fan of tools that are licensed on a per-use basis, but with a product like this there are only so many ways to license it. For larger projects, I hope Double-Take’s site licensing won’t be too unattractive.

The second new product, Double-Take Flex, allows organizations to boot systems via an iSCSI SAN without the need for expensive iSCSI hardware initiators. Any ordinary Ethernet NIC within a server or desktop can be used to iSCSI boot and enable diskless operation. In addition, Double-Take Flex contains an iSCSI target for Windows Server, allowing smaller organizations to build their own iSCSI SANs. When using the Double-Take Flex iSCSI target, organizations also gain the ability to share base images, so that the storage requirements are greatly reduced and management of the OS image is simplified. I would love to have seen this sort of support with enterprise iSCSI targets like those provided by NetApp, EMC, HP, and others, but for now the shared image support is limited to Double-Take’s own iSCSI target implementation. Double-Take assured me that APIs are available to allow other vendors to add this support to their systems; only time will tell if anyone actually takes advantage of those APIs.

Both Double-Take Move and Double-Take Flex provide management consoles for ease of administration.

More information on Double-Take Move, Double-Take Flex, and the rest of the Workload Optimization Suite is available from Double-Take’s web site.

Tags: , , , , ,

NetApp has recently released TR-3747, Best Practices for File System Alignment in Virtual Environments. This document addresses the situations in which file system alignment is necessary in environments running VMware ESX/ESXi, Microsoft Hyper-V, and Citrix XenServer. The authors are Abhinav Joshi (he delivered the Hyper-V deep dive at Insight last year), Eric Forgette (wrote the Rapid Cloning Utility, I believe), and Peter Learmonth (a well-recognized name from the Toasters mailing list), so you know there’s quite a bit of knowledge and experience baked into this document.

There are a couple of nice tidbits of information in here. For example, I liked the information on using fdisk to set the alignment of a guest VMDK from the ESX Service Console; that’s a pretty handy trick! I also thought the tables which described the different levels at which misalignment could occur were quite useful. (To be honest, though, it took me a couple of times reading through that section to understand what information the authors were trying to deliver.)

Anyway, if you’re looking for more information on storage alignment, the different levels at which it may occur, and the methods used to fix it at each of these levels, this is an excellent resource that I strongly recommend reading. Does anyone have any pointers to similar documents from other storage vendors?

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

« Older entries