ESXi

You are currently browsing articles tagged ESXi.

Virtualization Short Take #31

Welcome back to yet another Virtualization Short Take! Here is a collection of virtualization-related items—some recent, some not, but hopefully all interesting and/or useful.

  • Matt Hensley posted a link to this VIOPS document on how to setup VMware SRM 4.0 with an EMC Celerra storage array. I haven’t had the chance to read through it yet.
  • Jason Boche informs us that both Lab Manager 3 and Lab Manager 4 have problems with the VMXNET3 virtual NIC. In this blog post, Jason describes how his attempts to install Lab Manager server into a VM with the VMXNET3 NIC was failing. Fortunately, Jason provides a workaround as well, but you’ll have to read his article to get that information.
  • Bruce Hoard over at Virtualization Review (disclaimer: I write a regular column for the print edition of Virtualization Review) stirred up a bit of controversy with his post about Hyper-V’s three problems. The first problem is indeed a problem, but not an architectural or technological problem; VMware is indeed the market leader and has a quite solid user base. The second two “problems” stem from Microsoft’s architectural decision to embed the hypervisor into Windows Server. Like any other technology decision, this decisions has its advantages and disadvantages (these technology decisions are a real double-edged sword). Based on historical data, it would seem that the need to patch Windows Server will impact the uptime of the Windows virtualization solution; however, this is not to say that VMware ESX/ESXi are not without their patches and associated downtime as well. I guess the key takeaway here is that VMware seems to be doing a much better job of lessening (or even removing) the impact of the downtime through things like VMotion, DRS, HA, maintenance mode, and the like.
  • Apparently there is a problem with the GA release of the Host Update utility that is installed along with the vSphere Client, as outlined here by Barry Coombs. Downloading the latest version and reinstalling seems to fix the issue.
  • And while we are on the subject of ESX upgrades, here’s another one: if the /boot partition is too small, the upgrade to ESX 4.0.0 will fail. This isn’t really anything too new and, as Joep points out, is documented in the vSphere Upgrade Guide. I prefer clean installations of VMware ESX/ESXi anyway.
  • Dave Mishchenko details his adventures (part 1, part 2, and part 3) in managing ESXi without the VI Client or the vCLI. While it’s interesting and contains some useful information, I’m not so sure that the exercise is useful in any way other than academically. First of all, Dave enables SSH access to ESXi, which is unsupported. Second, while he shows that it’s possible to manage ESXi without the VI Client or the vCLI, it don’t seem to be very efficient. Still, there is some useful information to be gleaned for those who want to know more about ESXi and its inner workings.
  • I think Simon Seagrave and Jason Boche were collaborating in secret, since they both wrote posts about using vSphere’s power savings/frequency scaling functionality. Simon’s post is dated October 27; Jason’s post is dated November 11. Coincidence? I don’t think so. C’mon, guys, go ahead and admit it.
  • Thinking of using the Shared Recovery Site feature in VMware SRM 4.0? This VMware KB article might come in handy.
  • I’m of the opinion that every blogger has a few “masterpiece” posts. These are posts that are just so good, so relevant, so useful, that they almost transcend the other content on the blogger’s site. Based on traffic patterns, one of my “masterpiece” posts is the one on ESX Server, NIC teaming, and VLAN trunking. It’s not the most well-written post I’ve ever published, but it seems to have a lasting impact. Why do I mention this? Because I believe that Chad Sakac’s post on VMware I/O queues, microbursting, and multipathing is one of his “masterpiece” posts. Like Scott Drummonds, I’ve read that post multiple times, and every time I read it I get something else out of it, and I’m reminded of just how much I have yet to learn. Time to get back out of that comfort zone!
  • Oh, and speaking of Chad’s blog…this post is handy, too.

That’s all for now, folks. Stay tuned for the next installation, where I’ll once again share a collection of links about virtualization. Until then, feel free to share your own links in the comments.

Tags: , , , , , , ,

Virtualization Short Take #30

Welcome to Virtualization Short Take #30, my irregularly posted collection of links and thoughts on virtualization. I hope you find something useful here!

  • I believe Jason Boche already mentioned this on his own blog (I couldn’t find a link) and also started this VMware Communities thread discussing the fact that the 8/6 patch breaks FT compatibility between ESX and ESXi hosts in the same cluster. This VMware KB article is now available with more information on the problem. I’m hearing from VMware is that there is no short-term solution; the workaround is to use only ESX or only ESXi within a single cluster. (I don’t recommend not patching the hosts until the problem is fixed.)
  • And while we’re talking VMware FT, here’s a good document on VMware FT architecture and performance. (Eric Siebert’s Virtualization Pro blog post about VMware FT is really good, too.)
  • I’m also hearing reports that there are problems mixing ESX and ESXi in the same cluster when using host profiles. Theoretically, you should be able to use an ESX reference host and apply that to ESXi hosts, but in reality it’s not working so well.
  • If you’re using AppSpeed, you’ll need to manually turn off the AppSpeed sensor VMs in order to put ESX/ESXi hosts into Maintenance Mode. The sensor VM won’t VMotion off the host, so this prevents the host from entering Maintenance Mode.
  • Here’s another topic that I think has been mentioned elsewhere (looks like Duncan mentions it here), but SRM 1.0 Update 1 Patch 4 was released a couple of weeks ago and it includes a fit for customizing the IP addresses of Windows Server 2008 guest operating system instances.
  • Toward the end of August, VMware Infrastructure 3 support was added for NetApp MetroCluster (see this VMware KB article). Now, how about some VMware vSphere 4 support?
  • Most of you are aware by now (and if you aren’t aware, go buy a copy of my book so you will be aware) that you can use Storage VMotion to change virtual disks from thin provisioned to thick provisioned. The problem is this: the type of thick provisioned disk created when you do this via Storage VMotion is eagerzeroedthick, not zeroedthick. This means that it is not friendly to storage array thin provisioning!
  • I’m still looking for a valid use case for this little trick, but it’s mentioned by both Duncan and Eric: the ability to present multiple cores per socket to a virtual machine. Duncan’s post is here; Eric’s post is here. As Eric points out, licensing is one potential use. Anyone have any other valid use cases?
  • Eric Sloof has a great post on dvSwitch caveats and best practices that is definitely worth reading.
  • Want to make linked clones work on vSphere? Tom Howarth points out in this post some information made available by William Lam. Both articles are worth a look.
  • Tom also posted some useful information on enabling firewall logging on VMware ESX hosts.
  • This post over on Aaron Sweemer’s blog was actually written by guest author John Blessing (aka @vTrooper on Twitter) and just goes to illustrate how difficult it can be to create a chargeback model.
  • Of course, the “Super iSCSI Friends” recently produced a multi-vendor post on using iSCSI with VMware vSphere, a great follow-up to the original multi-vendor VI3 post. Here’s Chad’s version of the multi-vendor vSphere and iSCSI post.

That wraps it up for this time around. Thanks for reading, and feel free to submit any other useful or interesting links in the comments below.

Tags: , , , , , ,

Here’s Virtualization Short Take #27, a collection of news, tidbits, thoughts, articles, and useless trivia I’ve gathered over the last week or so. Perhaps you’ll find a diamond in the rough among these items!

  • Interested in more information on how it is, exactly, that Cisco is going to provide so much memory in their UCS blades and rack mount servers to make them ideal virtualization hosts? This article from CommsDesign and this “Catalina” article by Rodos Haywood both provide some great information on how Cisco is working around the Intel reference architecture limitations introduced with the Xeon 5500 and Quick Path Interconnect (QPI).
  • This article provides a handy reference on how to unregister the Nexus 1000V vCenter Server plug-in. I wish I’d known this information several weeks ago…
  • Need to view some configuration files on an ESX host? Just browse to http://<IP address of ESX server>/host and you’re all set. I learned of this handy little trick via Virtual Foundry.
  • And speaking of handy little tips, here’s one Eric Sloof shared regarding the vCenter Ops Dashboard. Again, just browse over to http://<IP address of vCenter Server>/vod/index.html to view the vCenter Ops Dashboard.
  • Adam Leventhal describes using the latest version of VirtualBox—which now includes OVF support and host-only networking—to run the Sun Storage 7000 Simulator. This is pretty cool stuff. I hope Oracle doesn’t kill it like Virtual Iron…
  • I just mentioned Virtual Foundry a bit ago, but forgot to mention this great post on hardening the VMX file. Good stuff.
  • For others who are, like myself, pursuing the elusive VMware Certified Design Expert (VCDX) certification, Duncan’s recent post describing the VCDX design defense is a great resource. Thanks, Duncan!
  • The VMware networking team addresses some questions around using VMware for virtualized DMZs, and how to protect against Layer 2 attacks.
  • Want to do manual linked clones in VMware Fusion? Here’s how.
  • Via Matt Hensley, I found this VIOPS document on configuring a VMware vCenter Data Recovery dedupe store.
  • This article has more information on installing ESXi 4.0 to a flash drive, a process I have yet to try. (Instructions for burning ESXi 3.5 to a flash drive can be found here.) Anyone else done it yet? I’d be interested in how it went.
  • If you have any questions about SAN multipathing, Brent Ozar’s two part series on the topic may help straighten things out (here’s Part 1 and Part 2). I’m not sure that I agree with Brent’s statement regarding the ability of desktop-class SATA drives to saturate 4Gbps Fibre Channel, but I’m no storage expert so I could very well be wrong.
  • VMware SE and friend Aaron Sweemer provides a handy script that can help fix Service Console networking when performing automated builds of VMware ESX.

That wraps it up for this edition of Virtualization Short Takes. Feel free to share thoughts, questions, or corrections in the comments, and thanks for reading!

Tags: , , , , , ,

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: , , , ,

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 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: , , , , , , ,

This post is not necessarily specific to next-generation ESX/ESXi and vCenter Server, but it was prompted by behaviors in these products. (Besides, the truth is that I’m really just trying to be sensationalist and capitalize on interest in the next-generation products.)

When you add an ESX/ESXi host to vCenter Server in the next generation of products, you will receive a security warning that displays the SHA1 thumbprint (or fingerprint) of the ESX/ESXi host’s default SSL certificate. The fact that the dialog box displays the SHA1 fingerprint got me to thinking—how does one go about verifying the SHA1 fingerprint to ensure that the host to which you are connecting is really the host you think it is? I mean, that’s the idea behind displaying the fingerprint, isn’t it? Paranoid people will then go to the specific host in question, generate the fingerprint on the SSL certificate, and then compare the two fingerprints to make sure they are identical.

I haven’t figured out a way to do this for ESXi yet, but for ESX you can verify the SHA1 fingerprint of the SSL certificate using this command:

openssl x509 -sha1 -in /etc/vmware/ssl/rui.crt -noout
-fingerprint

This should all be on a single line; I’ve wrapped it here for readability. The command will then display the SHA1 fingerprint on the SSL certificate, which you can compare to the fingerprint displayed in the vCenter Server dialog box to ensure that the two values match. (If you’re really paranoid, you’ll run this command at the server’s physical console and not remotely. Unless, of course, you took the time to actually verify the SSH key fingerprints when you first connected via SSH, but that’s an entirely different post.)

So, here’s the real question: how does one verify the SHA1 fingerprint for an ESXi host? The ideal solution should not require the use of any unsupported hacks. (And yes, I know that you can view the SSL certificate, and thus the SHA1 fingerprint, by connecting to the ESXi host remotely using a web browser. But you still don’t know for sure that the host to which you connected is the host you thought it was, do you?)

UPDATE: At the ESXi console, logging in and selecting the “View Support Information” menu item will display the SSL fingerprint. Challenge solved!

Tags: , , , , , , ,

Now that the veil appears to have been lifted on discussing features and functionality in the next-generation of ESX/ESXi, I thought I’d start out with a brief how-to on enabling Cisco Discovery Protocol (CDP) on ESX/ESXi, both with vNetwork Standard Switches (vSwitches) and vNetwork Distributed Switches (dvSwitches).

Let’s start out with an easy one: enabling CDP on ESX for a vSwitch. There is no GUI for enabling or disabling CDP for a vSwitch (yet), so it’s off to the CLI. You’ve probably seen this command before:

esxcfg-vswitch --set-cdp both vSwitch0

Replace the italicized parts of that command with the appropriate information for your environment. That sets CDP to both listen (receive CDP transmissions) and announce (send CDP transmissions). I recommend using both, although I have not currently found a way to explore the CDP information that ESX is gathering by listening to announcements. If anyone has any information there, I’d love to hear it.

The next one is a bit harder: enabling CDP on ESXi for a vSwitch. Of course, since we are using ESXi there is no Service Console, so this time we’ll have to rely upon the next-generation equivalent of VIMA.

The command from next-gen VIMA looks like this:

vicfg-vswitch --server vcenter.domain.com -h esxi.domain.com -B both vSwitch0

Unless you’ve set some environment variables, you’ll be prompted for username and password. I substituted the “-h” for “-−vihost” and “-B” for “-−set-cdp”. Again, you’ll need to replace the italicized portions with the appropriate information for your environment. I did find that using IP addresses didn’t seem to work well; I had to use fully-qualified domain names instead. That’s probably just an oddity.

The last scenario is enabling CDP on a dvSwitch. The process for this is the same for both ESX and ESXi. You’ll need to use the next-generation VI Client for this, and then go to the Edit Settings screen for the dvSwitch. Once there select Advanced, and you’ll see the option to set the CDP behavior. Click Both from the drop-down list and you should be good to go.

There’s lots more networking goodness in here; stay tuned for more articles in the near future.

Tags: , , , ,

« Older entries