Home > Blogs > VMware vSphere Blog > Category Archives: ESXi

Category Archives: ESXi

Configuring PXE to support multiple Auto Deploy Servers

One question I constantly receive from customers is how they can use Auto Deploy with their current TFTP solution, often they may have an existing TFTP server but still want to make use of AutoDeploy stateless installs to easily deploy and manage their ESXi hosts.  This can also fall under the question of how can I deploy two sets of hosts to different vCenters on the same VLAN?

Both of these questions can be addressed in this post, the key thing to keep in mind is how we will be designing the DHCP/PXE/TFTP infrastructure to use AutoDeploy, there are multiple ways to achieve this depending on your companies environment and what best fits into your infrastructure. I have often heard from customers that they are unable to use AutoDeploy because they already have a PXE infrastructure, this is not always a roadblock.

Scenario

The scenario I have used for this post is that we have two vCenters, there is a vCenter for Infrastructure and a vCenter for the VDI environment, in this scenario we have a very simple network and both infrastructures are on the same network and the same VLAN.

Continue reading

“It’s a Unix system, I know this!”

Every fellow geek who first saw Jurassic Park twenty years ago (Has it really been that long??) cringed when Lex Murphy sat down at a Silicon Graphics workstation and exclaimed the line above. I’m reminded of this line all the time when I talk to some customers who I find treat their ESXi systems like they would a Unix or Linux system. I’m here to tell you, it’s not.

A shell does not an OS make

Screen Shot 2013-06-18 at 6.12.03 PM

Did you know you can run a Unix bash shell on Windows? Heck, you can even run a Unix bash shell on OpenVMS! Neither of them are Unix systems, obviously! And neither is ESXi.

Logging into an ESXi shell, whether via SSH or via the local console using ALT-F1, brings you into a Unix-like shell.

Continue reading

Preview – VMworld 2013 Extreme Performance Series: vCenter of the Universe

Previous entry: Preview – Extreme Performance Series: Monster Virtual Machines

Next in our Extreme Performance Series mini-track, I’d like to highlight the following vCenter performance breakout.  Remember, you’ll want to attend the whole series to learn about performance across the stack.

Continue reading

Preview – Extreme Performance Series: Monster Virtual Machines

This year at VMworld (both San Francisco and Barcelona) performance will be front and center.  I’ve been working internally to create a “mini-track” of technically advanced performance breakouts with many of our actual performance engineers as speakers.  Customers always want to know about best practices, troubleshooting and just how far vSphere can push the performance envelope and that’s very hard to do in a 60 minute session.  So this year I’ve got approval to try something different. Continue reading

Grant shell access to this user? No worries mate!

A few weeks ago I saw on an internal email thread an ask from a customer via their VMware sale engineer. The customer was using AutoDeploy and Host Profiles. As part of this process, they were creating a local user on their ESXi hosts and when they connected to the host via the vSphere Client application on Windows, they were worried to see that the user was created with Shell Access already granted! As you can imagine, that’s probably not something you want done by default. Even more so when you’re in an environment that has compliance concerns. And especially when you have the Security Guy looking over your shoulder!

Well, like our friends from Down Under would say, “No Worries Mate”. What you are seeing here is a UI bug in the vSphere Windows Client. As you know, the vSphere Windows Client has been superseded by the new vSphere Web Client. But at the moment, it’s the main tool for configuration by those who connect to ESXi servers. With the vSphere Web Client being the current and future client user interface for vCenter Server managed objects and resources, the “old” vSphere Client may, at times, not be as current as we’d like.

Continue reading

Proving Performance: Hadoop On vSphere – A Bare Metal Comparison

When architects think about putting big data and Apache Hadoop on virtualized commodity servers they usually see virtualization as a performance deterrent.  Virtualization software is just that—software. Additional software layers are overhead and they must make it run slower.

Not true.

In a recent performance study by VMware, they demonstrated that performance between bare-metal deployments and virtualized deployments can even exceed bare-metal performance in certain cases when using multiple virtual machines allowing for parallelism.

Just like the data industry proved that distributed querying is faster and more scalable than a single monolithic source, VMware believes that performance can improve with virtualization and is working on a variety of projects including Hadoop Virtualization Extensions (HVE) and Serengeti, as well as working with vendors like Cloudera to certify their Hadoop distributions on vSphere. Continue reading

New Component-Based Logging For Hostd In ESXi 5.1 Update 1

vSphere 5.1 Update 1 was just released last week and one of the things that caught my eye while reading through the release notes for ESXi 5.1 Update 1 was a new enhancement to hostd logging:

  • Component-based logging and advanced configurations added to hostd log level
    • To avoid difficulties in getting appropriate logs during an issue, this release introduces component-based logging by dividing the loggers into different groups and prefixing them. Also, new advanced configuration allows you to change hostd log’s log level without restarting.

Though this enhancement is targeted for troubleshooting purposes and will most likely be used when working with GSS. I thought I would walk you through on how this feature works as there were not much detail in the release notes.

Continue reading

Did you know vCenter Server can manage multiple hypervisors?

VMware vCenter Multi-Hypervisor Manager is a component that enables support for heterogeneous hypervisors in a VMware vCenter Server environment. It provides the following benefits to your virtual environment:

 
  • An integrated platform for managing VMware and third-party hypervisors from a single interface.
  • A hypervisor choice for the different business units in your organization to accommodate their specific needs.
  • No single hypervisor vendor lock-in.

When you add a third-party host to vCenter Server, all virtual machines that exist on the host are discovered automatically, and are added to the third-party hosts inventory.

The ability of vCenter Multi-Hypervisor Manager to migrate virtual machines from third-party hosts to ESX or ESXi hosts is implemented by exposing the capabilities of vCenter Converter Standalone in the vSphere Client. See VMware KB article 2048927 for information about dependency between vCenter Multi-Hypervisor Manager and vCenter Converter Standalone.

Key Capabilities

vCenter Multi-Hypervisor Manager 1.1 introduces the following set of basic management capabilities over third-party hosts:

  • Third-party host management including add, remove, connect, disconnect, and view the host configuration.
  • Ability to migrate virtual machines from third-party hosts to ESX or ESXi hosts.
  • Ability to provision virtual machines on third-party hosts.
  • Ability to edit virtual machine settings.
  • Integrated vCenter Server authorization mechanism across ESX/ESXi and third-party hosts inventories for privileges, roles, and users.
  • Automatic discovery of pre-existing third-party virtual machines
  • Ability to perform power operations with hosts and virtual machines.
  • Ability to connect and disconnect DVD, CD-ROM, and floppy drives and images to install operating systems.

Continue reading

vSphere 5.1 Update 1 Released!

VMware has just released the much anticipated Update 1 patch for vSphere 5.1 which includes several updates and bug fixes for both ESXi and vCenter Server 5.1. I highly encourage everyone to review the release notes for the complete list of resolved issues. While going through the ESXi 5.1 Update 1 release notes myself, I noticed a few resolved bugs that I had been following and thought I would highlight a few of them:

  • Reinstallation of ESXi 5.1 does not remove the Datastore label of the local VMFS of an earlier installation
    • Re-installation of ESXi 5.1 with an existing local VMFS volume retains the Datastore label even after the user chooses the overwrite datastore option to overwrite the VMFS volume.
  • resxtop fails when upgraded from vSphere 5.0 to vSphere 5.1
    • In vSphere 5.1, SSL certification checks are turned ON. This might cause resxtop to fail in connecting to hosts and displays an exception message similar the following: HTTPS_CA_FILE or HTTPS_CA_DIR not set. (More details about this issue can be found in this blog article)
  • Using the invoke-vmscript command displays an error
    • When you use the invoke-vmscript powercli command scripts on the virtual machine, the script fails with the following error message:

One interesting thing that caught my eye while going through the release note is the following:

  • Component-based logging and advanced configurations added to hostd log level
    • To avoid difficulties in getting appropriate logs during an issue, this release introduces component-based logging by dividing the loggers into different groups and prefixing them. Also, new advanced configuration allows you to change hostd log’s log level without restarting.

It looks like you now have the ability to configure granular log levels for various components within hostd which can better assist during troubleshooting and log collection. I will discuss how this works in more detail in another blog article.

There are many more resolved issues and you can check out the rest of the fixes in the ESXi 5.1 release notes.

Get notification of new blog postings and more by following lamw on Twitter:  @lamw

Understanding ESXi Patches – Size & Patch Bundles

Patch management for ESXi is very different compared to traditional operating system patches, where incremental updates are made to the base operating system and thus increasing the disk footprint for each patch update. For the ESXi hypervisor, when a patch is applied, the entire ESXi image also known as an Image Profile is replaced. This means that each time you patch or upgrade your ESXi host, you are not adding on top of the original installation size.

Continue reading