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

Tag Archives: ESXi

Introducing the VIB Author Fling

I’m very excited to announce the new vibauthor fling.  This fling is hot off the press and provides the capability to create custom vSphere Installation Bundles (VIBs).  Prior to this fling the VIB authoring tools were only available to VMware partners, this fling now extends this capability to everyone.

There are a couple of use cases for creating custom VIBs.  For example, if you are using Auto Deploy and you need to add a custom firewall rule to your host, or you need to make a configuration change that can’t be made using Host Profiles.

One word of caution however, the ability to create custom VIBs does come with some responsibility.  If you plan to create your own VIBs here are a few things to keep in mind:

  1. VIBs provided by VMware and trusted partners are digitally signed, these digital signatures ensure the integrity of the VIB.  Custom VIBs are not digitally signed.  Be careful when adding unsigned VIBs to you ESXi hosts as you have no way of vouching for the integrity of the software being installed.
  2. Before adding a custom VIB you will need to set your host’s acceptance level to “Community Supported”.   When running at the community supported acceptance level it’s important to understand that VMware support may ask you to remove any custom VIBs.   Here’s the formal disclaimer:

IMPORTANT If you add a Community Supported VIB to an ESXi host, you must first change the host’s acceptance level to Community Supported. If you encounter problems with an ESXi host that is at the CommunitySupported acceptance level, VMware Support might ask you to remove the custom VIB, as outlined in the support policies:”

 

If you are not familiar with VIBs I recommend you start with a quick review of this blog: http://blogs.vmware.com/esxi/2011/09/whats-in-a-vib.html

With that, I know several folks have been chomping at the bit to create their own custom VIBs so I’ve attached a short tutorial that shows how to use the vibauthor tool to create a  VIB to add a custom firewall rule.

Enjoy!

vibauthor-how-to-v0.1

vSphere 5.1 – Auto Deploy Stateless Caching and Stateful Installs

The following is an excerpt from my “What’s New in VMware vSphere 5.1 – Platform” white paper that introduces the new Auto Deploy Stateless Caching and Stateful Install modes. You can download the white paper from here.

vSphere 5.0 introduced VMware vSphere Auto Deploy, a new way to rapidly deploy new vSphere hosts.  With Auto Deploy, the vSphere host PXE boots over the network and is connected to an Auto Deploy server, where the vSphere host software is provisioned directly into the host’s memory.  After the software has been installed on the host, it is connected to the VMware® vCenter™ Server (vCenter) and configured using a host profile.

Auto Deploy significantly reduces the amount of time required to deploy new vSphere hosts.  And because an Auto Deploy host runs directly from memory, there is no requirement for a dedicated boot disk.  This not only provides cost savings, because there is no need to allocate boot storage for each host, but it also can simplify the SAN configuration, because there is no need to provision and zone LUNs each time a new host is deployed.  In addition, because the host configuration comes from a host profile there is no need to create and maintain custom pre- and postinstall scripts.

Along with the rapid deployment, cost savings and simplified configuration, Auto Deploy provides the following benefits:
• Each host reboot is comparable to a fresh install.  This eliminates configuration drift.
• With no configuration drift between vSphere hosts, less time will be spent troubleshooting and diagnosing configuration issues.
• Simplified patching and upgrading.  Applying updates is as easy as creating a new image profile, updating the corresponding rule on the Auto Deploy server and rebooting the hosts.  In the unlikely event you must remove an update, reverting back to the previous image profile is also easy: 1) Reupdate the rule to assign the original image profile and 2) do another reboot.

NOTE: Because an Auto Deploy host runs directly from memory, it often is referred to as being “stateless.” This is because the host state (i.e., configuration) that is normally stored on a boot disk comes from the vCenter Host Profile.

In vSphere 5.0 Auto Deploy supported only one operational mode, which was referred to as “stateless” (also known as “diskless”).  vSphere 5.1 extends Auto Deploy with the addition of two new operational modes: “Stateless Caching” and “Stateful Installs”.

Continue reading

VMware Posters

This page is dedicated to the VMware posters which were created by Technical Marketing and have been released at VMworld and VMUGs around the world, this is a central place to find the latest versions of the PDF versions which can be used for reference or printed off as needed.

If you didn’t enter this post with the short URL then remember, to get here just use: http://vmware.com/go/posters/

Use the following links to jump straight to the correct area of this page:

VMware vCloud Suite

Click here to download the PDF.

image

VMware ESXi 5.1 Reference Poster

Click here to download the PDF. (Please see the bottom of this page for important information)

ESXi Poster

VMware Management with PowerCLI 5.1 Poster

Click here to download the PDF.

PowerCLI Poster

VMware vCloud Networking Poster

Click here to download the PDF. (Last updated Sept 13 2012)

VMware vCloud Networking

VMware Hands-On Labs 2013 Poster

Click here to download the 2013 PDF.

VMware 2013 HOL Poster

VMware vCloud SDKs Poster (1.0 – Out of date)

Click here to download the PDF.

vCloud SDK Poster

Poster Printing Details

The following sizes (inches) are normally used when sending these PDF files to be professionally printed, the posters should also be produced as a vector and are therefore scalable to multiples of the sizes listed below, if you are looking to print in high resolution, you should print in no lower than 300 dpi:

  • vCloud Suite poster – 34 x 22
  • PowerCLI 5.1 poster – 42 x 22
  • Hands On Lab Reference – 33 x 17
  • vCloud Networking – 44 x 30.5
  • ESXi 5.1 Reference – 34 x 22

Poster Issues and Corrections:

The following issues and corrections are part of the distributed hard copy posters and PDF files received before October 13th 2012, the current uploaded PDF in this post has these corrections included.

ESXi 5.1 Reference Poster

Use the following correct code instead of the code available on the poster, the poster code will cause an error.

List Registered VMs (vCLI only)

# vmware-cmd -l

Register a VM (vCLI)

# vmware-cmd -s register /vmfs/volumes/<volume name>/<vm>/<vm>.vmx <datacenter> <resource pool>

Unregister a VM (vCLI only)

# vmware-cmd -s unregister /vmfs/volumes/<volume name>/<vm>/<vm>.vmx

Get VM power state (vCLI only)

# vmware-cmd /vmfs/volumes/<volume name>/<vm>/<vm>.vmx getstate

Power on a VM (vCLI only)

# vmware-cmd /vmfs/volumes/<volume name>/<vm>/<vm>.vmx start

Shutdown a VM (vCLI only)

# vmware-cmd /vmfs/volumes/<volume name>/<vm>/<vm>.vmx stop [ soft | hard ]

Power off a VM (vCLI only)

# vmware-cmd /vmfs/volumes/<volume name>/<vm>/<vm>.vmx stop [ soft | hard ]

Reset a VM (vCLI only)

# vmware-cmd /vmfs/volumes/<volume name>/<vm>/<vm>.vmx reset [soft | hard ]

Suspend a VM (vCLI only)

# vmware-cmd /vmfs/volumes/<volume name>/<vm>/<vm>.vmx suspend [soft | hard ]

Resume a VM (vCLI only)

# vmware-cmd /vmfs/volumes/<volume name>/<vm>/<vm>.vmx resume [soft | hard ]

Get ESXi Host Platform Information (vCLI only)

# vmware-cmd /vmfs/volumes/<volume name>/<vm>/<vm>.vmx getproductinfo [ product | platform | build | majorversion| minorversion ]

Get VM Uptime (vCLI only)

# vmware-cmd /vmfs/volumes/<volume name>/<vm>/<vm>.vmx getuptime

Get VMware Tools Status (vCLI only)

# vmware-cmd /vmfs/volumes/<volume name>/<vm>/<vm>.vmx gettoolslastactive

0 = Not installed/Not running

1 = Normal

5 = Intermittent Heartbeat

100 = No heartbeat. Guest operating system might have stopped responding

Create VM Snapshot (vCLI only)

# vmware-cmd /vmfs/volumes/<volume name>/<vm>/<vm>.vmx createsnapshot <name> <desc> <quiesce> <memory>

quiesce = Quiesce filesystem w/VMware Tools [ 0 | 1 ]

memory = Include memory state in snapshot [ 0 | 1 ]

Check if VM has a Snapshot (vCLI only)

# vmware-cmd /vmfs/volumes/<volume name>/<vm>/<vm>.vmx hassnapshot

Revert to VM Snapshot (vCLI only)

# vmware-cmd /vmfs/volumes/<volume name>/<vm>/<vm>.vmx revertsnapshot

Commit VM Snapshot (vCLI)

# vmware-cmd /vmfs/volumes/<volume name>/<vm>/<vm>.vmx removesnapshot

Forcibly Stop a VM with ESXCLI

# esxcli vm process list

# esxcli vm process kill –type [ soft | hard | force ] -w <worldId>

soft = similiar to kill or kill -SIGTERM

hard = similiar to kill -9 or kill -SIGKILL

force = use as a last resort

Under the “Virtual Machine Capabilities”.  The max VM video memory for all versions is listed in KB instead of MB.

Joining vSphere Hosts to Active Directory

I recently blogged about how in vSphere 5.1 you can now assign full admin privileges to named users, and in that post I commented that while it is possible to create local user accounts on each vSphere host that a better approach is to add your host to a Microsoft Active Directory (AD) domain and use your existing AD credentials instead.  In this post I will provide an example showing how to do this.

Note that although the ability to assign full admin privileges to local users is new in vSphere 5.1, the ability to join vSphere hosts to active directory is not new.  In this example I’m using vSphere 5.0.

Prerequisites

Of course before you can add your vSphere hosts to AD you need to have an AD domain.  In addition you need to have a domain admin account with the rights to add computers to the domain.

Continue reading

What’s New In ESXCLI 5.1

With the release of vSphere 5.1, there have been some major enhancements to ESXCLI which is part of the vCLI 5.1 release, also available with the latest vMA 5.1. Here’s a quick summary overview of the ESXCLI top level root namespaces that have received updates.

82 new ESXCLI commands:

  • 7 hardware

  • 2 sched

  • 47 network

  • 15 storage

  • 11 system

In addition to the new ESXCLI commands for vSphere 5.1 features, we continue to bring further parity from some of our legacy esxcfg-* and vicfg-* commands over to ESXCLI and to standardize on a common command-line interface for host configuration and management. In this release, we have introduced the following new namespaces:

Previous Command New ESXCLI Command
esxcfg-route/vicfg-route esxcli network ip route
vicfg-snmp esxcli system snmp
vicfg-hostops (maintenance mode) esxcli system maintenanceMode
vicfg-hostops (shutdown/reboot) esxcli system shutdown

For more details on all the new ESXCLI commands, please take a look at the release notes here. Also stay tuned for upcoming blogs posts in which we will be exploring some of the new ESXCLI 5.1 commands in greater detail!

Download: vSphere CLI 5.1

Also don’t forget to check out our updated VMware ESXi reference poster which has recently been refreshed for ESXi 5.1 and you can download your copy here.

Additional Information

If you are visiting VMworld Europe in 2012 make sure you add  INF-VSP1252 – What’s New with vSphere 5.1 – ESXCLI & PowerCLI to your session list and we hope to see you there!

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

vSphere 5.1 – New ESXiShellInteractiveTimeOut

I last blogged about how vSphere 5.1 removes the dependency on a shared root account by allowing you to assign full admin rights to non-root users (aka named users).   Today I want to talk about another nice security feature that has been added in vSphere 5.1, and that is the ability to automatically terminate idle ESXi Shell connections.

The new ESXiShellInteractiveTimeOut compliments the existing ESXiShellTimeOut that has existed in ESXi for a while.  As the names are very similar it’s easy to get confused between the two so I’ll go over both these settings.

Continue reading

vSphere 5.1 – Full Admin Support for Named User Accounts

Nestled among the many new features and capabilities introduced with vSphere 5.1 are some nice security improvements to the ESXi Shell.  One of the more notable improvements is the ability to assign full admin privileges to named user accounts.  This means there is no longer a dependency on a shared “root” account when working from the ESXi Shell.

Continue reading

VMworld 2012: Auto Deploy , ESXi Security, and vSphere Upgrades

Posted 15 Aug 2012 by Kyle Gleed, Sr. Technical Marketing Architect, VMware

What do Auto Deploy, ESXi Security and vSphere Upgrades have in common?  These are the three VMworld 2012 breakout sessions I'll be presenting at this year.  I’ve been a little out of pocket the past few days working on the slides and am glad to finally have them done (well, mostly done ;).  Now I just need to find a way to resist the urge to keep tweaking things.

As usual, there are a lot of great breakout sessions lined up and seats are filling up quickly.  Going through the list has really got me stoked; I can’t wait for things to kick off.  As we’re less than two weeks away I want to take a minute and throw out a plug for my sessions.  I hope to see you there!

INF-VSP1364: Architecting Auto Deploy for Availability and Scalability

Monday, 10:30AM – 11:30AM

Wednesday, 2:00PM – 3:00PM

Auto Deploy is all about making life easy when it comes to provisioning and repurposing ESXi hosts.  Learn how to architect a highly available and highly scalable Auto Deploy infrastructure for your datacenter. 

INF-VSP1365: Understanding VMware ESXi Security

Tuesday, 1:30PM – 2:30PM

Wednesday, 12:30PM – 1:30PM

In this session YatinPatil (ESXi Product Manager) and I will discuss ESXi security and show how the vSphere hypervisor aligns itself with generally accepted security best practices.

INF-VSP1367: Upgrading vSphere

Monday, 1:00PM – 2:00PM

Tuesday, 3:00PM – 4:00PM

This session is all about upgrading vSphere.  I’ll provide an overview of the upgrade process, show you what’s going on under the covers and pass along some helpful tips to ensure a successful upgrade with minimal disruption to your virtual machines.

GD24, vSphere ESXi Hypervisor with Kyle Gleed

Monday, 2:30PM – 3:30PM

This is an informal group discussion where you get to decide the topic.  Bring your ESXi related questions and lets talk about it.

Follow me on Twitter @VMwareESXi

Creating an ISO Image from a VMware Patch File

Posted on 25 July, 2012 by Kyle Gleed, Sr. Technical Marketing Architect, VMware

Ever wondered how to create an ISO image from a patch that was downloaded from VMware’s web site?  Here are the steps: 

(1) Download the patch from VMware's web site.  For help with the patch portal check here.  At the time I’m writing this the latest 5.0 patch is "ESXi500-201207001.zip" so I’ll use it.  As an FYI, here’s a link to the patch release notes.

(2) Start PowerCLI and import the patch using the “Add-EsxSoftwareDepot” cmdlet:

2

Continue reading

VAAI Offload Failures & the role of the VMKernel Data Mover

Before VMware introduced VAAI (vSphere Storage APIs for Array Integration), migrations of Virtual Machines (and their associated disks) between datastores was done by the VMkernel Data Mover (DM).

The Data Mover aims to have a continuous queue of outstanding IO requests to achieve maximum throughput. Incoming I/O requests to the Data Mover are divided up into smaller chunks. Asynchronous I/Os are then simultaneously issued for each chunk until the DM queue depth is filled. When a request completes, the next request is issued. This could be for writing the data that was just read, or to handle the next chunk.

Take the example of a clone of a 64GB VMDK (Virtual Machine Disk file). The DM is asked to move the data in 32MB transfers. The 32MB is then transferred in "PARALLEL" as a single delivery, but is divided up into a much smaller I/O size of 64KB by the DM, using 32 threads at a time. To transfer this 32MB, a total of 512 I/Os of size 64KB is issued by the DM.

By comparison, a similar a 32MB transfer via VAAI issues a total of 8 I/Os of size 4MB (XCOPY uses 4MB transfer sizes). The advantages of VAAI in terms of ESXi resources is immediately apparent. 

The decision to transfer using the DM or offloading to the array with VAAI is taken upfront by looking at storage array Hardware Acceleration state. If we decide to transfer using VAAI and then encounter a failure with the offload, the VMkernel will try to complete the transfer using the VMkernel DM. It should be noted that the operation is not restarted; rather it picks up from where the previous transfer left off as we do not want to abandon what could possibly be very many GB worth of copied data because of a single transient transfer error.

If the error is transient, we want the VMkernel to check if it is ok to start offloading once again. In vSphere 4.1, the frequency at which an ESXi host checks to see if Hardware Acceleration is supported on the storage array is defined via the following parameter:

 # esxcfg-advcfg -g /DataMover/HardwareAcceleratedMoveFrequency
Value of HardwareAcceleratedMoveFrequency is 16384

This parameter dictates how often we will retry an offload primitive once a failure is encountered. This can be read as 16384 * 32MB I/Os, so basically we will check once every 512GB of data move requests. This means that if at initial deployment, an array does not support the offload primitives, but at a later date the firmware on the arrays gets upgraded and the offload primitives are now supported, nothing will need to be done at the ESXi side – it will automatically start to use the offload primitive.

HardwareAcceleratedMoveFrequency only exists in vSphere 4.1. In vSphere 5.0 and later, we replaced it with the periodic VAAI state evaluation every 5 minutes.

Get notification of these blogs postings and more VMware Storage information by following me on Twitter: Twitter @VMwareStorage