VMware ESX and ESXi Comparison

Capability	VMware ESX	VMware ESXi
Service Console	Service Console is a standard Linux environment through which a user has privileged access to the VMware ESX kernel. This Linux-based privileged access allows you to highly customizing your environment by installing agents and drivers and executing scripts and other Linux-environment code.	VMware ESXi is designed to make the server a computing appliance. Accordingly, VMware ESXi behaves more like firmware than traditional software. To provide hardware-like security and reliability, VMware ESXi does not support a privileged access environment like the Service Console of VMware ESX. To enable interaction with agents, VMware has provisioned CIM Providers through which monitoring and management tasks – traditionally done through Service Console agents – can be performed. VMware has provisioned RCLI to allow the execution of scripts.
Remote CLI	VMware ESX Service Console has a host CLI command through which VMware ESX can be configured. ESX 3.5 Update 2 supports RCLI.	VMware ESX Service Console CLI has been ported to a Remote CLI (RCLI) for VMware ESXi. RCLI is a virtual appliance that interacts with VMware ESXi hosts to enable host configuration through scripts or specific commands. Note: RCLI is limited to read-only access for the free version of VMware ESXi. To enable full functionality of RCLI on a VMware ESXi host, the host must be licensed with VI Foundation, VI Standard, or VI Enterprise. The following Service Console CLI commands have not been implemented in RCLI: ESXcfg-info ESXcfg-resgrp ESXcfg-swiscsi
Scriptable Installation	VMware ESX supports scriptable installations through utilities like KickStart.	VMware ESXi Installable does not support scriptable installations in the manner ESX does, at this time. VMware ESXi does provide support for post installation configuration script using RCLI-based configuration scripts.
Serial Cable Connectivity	VMware ESX supports interaction through direct-attached serial cable to the VMware ESX host.	VMware ESXi does not support interaction through direct-attached serial cable to the VMware ESXi host at this time.
SNMP	VMware ESX supports SNMP.	VMware ESXi supports SNMP when licensed to a VI Foundation, VI Standard, or VI Enterprise edition. The free version of VMware ESXi does not support SNMP.
Active Directory Integration	VMware ESX supports Active Directory integration through third-party agents installed on the Service Console.	VMware ESXi with a Virtual Infrastructure license and in conjunction with VirtualCenter allows users to be authenticated via Active Directory. In this configuration, users can log in directly to an ESXi host and authenticate using a local username and password. The free version of VMware ESXi does not support Active Directory integration at this time.
HW Instrumentation	Service Console agents provide a range of HW instrumentation on VMware ESX.	VMware ESXi provides HW instrumentation through CIM Providers. Standards-based CIM Providers are distributed with all versions of VMware ESXi. VMware partners may inject their own proprietary CIM Providers in customized versions of VMware ESXi. To obtain a customized version of VMware ESXi, you typically have to purchase a server with embedded VMware ESXi through a server vendor. At this time, HP also offers its customized VMware ESXi Installable on www.vmware.com. Dell and IBM will soon offer their customized version of VMware ESXi on www.vmware.com. Remote console applications like Dell DRAC, HP iLO, and IBM RSA are supported with ESXi. Note: COS agents have a longer lineage than CIM Providers and are therefore more mature. VMware is actively working with its 250+ partners to close the CIM Provider–Service Console agent gap.
Software Patches and Updates	VMware ESX software patches and upgrades behave like traditional Linux based patches and upgrades. The installation of a software patch or upgrade may require multiple system boots as the patch or upgrade may have dependencies on previous patches or upgrades.	VMware ESXi patches and updates behave like firmware patches and updates. Any given patch or update is all-inclusive of previous patches and updates. That is, installing patch version “n” includes all updates included in patch versions n-1, n-2, and so forth.
VI Web Access	VMware ESX supports managing your virtual machines through VI Web Access. You can use the VI Web Access to connect directly to the ESX host or to the VMware Infrastructure Client.	VMware ESXi does not support web access at this time.
Licensing	VMware ESX hosts can be licensed as part of a VMware Infrastructure 3 Foundation, Standard, or Enterprise suite.	VMware ESXi hosts can be individually licensed (for free) or licensed as part of a VMware Infrastructure 3 Foundation, Standard, or Enterprise suite. Individually licensed ESXi hosts offer a subset of management capabilities (see SNMP and Remote CLI).

	ESXi (ESX not available without VI)	VI Foundation (with ESX or ESXi)	VI Standard (with ESX or ESXi)	VI Enterprise (with ESX or ESXi)
Core hypervisor functionality	Yes	Yes	Yes	Yes
Virtual SMP	Yes	Yes	Yes	Yes
VMFS	Yes	Yes	Yes	Yes
VirtualCenter Agent		Yes	Yes	Yes
Update Manager		Yes	Yes	Yes
Consolidated Backup		Yes	Yes	Yes
High Availability			Yes	Yes
VMotion				Yes
Storage VMotion				Yes
DRS				Yes
DPM

ESX3: Scripted Install is disabled

When you click the Log In To Script Installer link, you are presented with the following error

To fix this problem you will need to login as ‘root’ to the console of your ESX host and edit a file. By default the scripted installer applet is disabled - to enable it follow the process below:

1. Log in to the console using your root account

2. Using VI or NANO open the following file /usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/webapps/ui/WEB-INF/struts-config.xml

3. We need to comment out and un-comment some lines. Luckily they are in the same section. You need to find the scripted install handler section.

4. I have marked in red the line of code we need to comment out and the section to un-comment in blue, in the picture below.

To comment out the line, we use the <!– to start the comment and close the comment using –>

5. In the screenshot below you can see the changes we have made to the section. Save the changes and exit the editor.

6. To have our changes take effect the configuration file needs to be re-read by the web server so we will need to restart the webAccess service.

Enter service vmware-webAccess restart to restart the webAccess service

Bron: xtravirt

Watching your ESX server performance in real time with ESXTOP

Very few people understand the power of the VMware Console. Even fewer know the power of esxtop, a command-line real-time monitor for the vmkernel. You can get more information here.

One of the most awesome things about esxtop is that it’s minimally intensive on resources and can be run interactively, as a batch mode or as replay worlds.

However the practice of logging in and running it with root logged in on every ESX host is a little annoying and exposes anyone with basic knowledge to the Ctrl-C kill command, and then the root prompt. Which is bad.

What I do on some of my sites is similar to what VMware does on tty11 (Ctrl+Alt+F11) – the VMware ESX Service Console Welcome Screen. Essentially, I output a dynamic interactive esxtop to one of the available tty’s (tty7-12 are disabled in ESX 3.x, so you have to use 1-5, 6 is the emergency console)

Here’s what you need to do edit in the/etc/inittab file:

Edit out the mingetty tty5 terminal by making this line:

5:2345:respawn:/sbin/mingetty tty5

…look like this:

#5:2345:respawn:/sbin/mingetty tty5

Then, insert the following bolded lines after the non-bolded line which should already exist in your /etc/inittab:

6:2345:respawn:/sbin/mingetty -f /etc/issue.emergency -l /bin/login.emergency tty6

# Output ESXTOP to Console/tty5
esxtop:2345:respawn:/usr/bin/esxtop -d 2 -s > /dev/tty5 < /dev/tty5

After this, reboot your ESX server and watch console 5 (Ctrl+Alt+F5) – you will see all your vmkernel performance stats, and you can control them interactively as per the instructions for esxtop which you can find by running man esxtop in the service console. Or you can read the documentation here.

Bron: http://lraikhman.blogsite.org

Hyper-V for the ESX Engineer

Aaron Delp over at BladeVault.info recently published a good article on Hyper-V for the ESX Engineer.

Read it below.

I just attended a great session on Microsoft Hyper-V.  Before I go into my notes, let me give you my background to better frame this post.  I used to be an MCSE (NT4!) but I really haven’t touched Microsoft products in a number of years.  My focus has been on hardware architecture and eventually this has led me into the virtual architecture as it has gained acceptance into the market place.  If some of my highlights seem a little different than most posts out there, it is because I am making the ESX to Hyper-V mapping in my head.  I know ESX, I don’t know Windows Server 2008 (or 2003 for that matter).

With that out of the way, here are my points of interest in no particular order.

• Hyper-V is paravirtualized – paravirtualized means the virtual machine is “aware” (Microsoft uses the term enlightened) that it is virtualized.  If the machine isn’t enlightened, it will run in emulation mode.  Emulation mode requires a lot of context switching between user mode and kernel mode.  This will understandably slow down performance.
• The Hyper-V “Service Console” is referred to as the Management Partition.  This is a Windows VM with privileges into the kernel that other VMs do not have.  This (at least on the surface) is similar to ESX’s Service Console.
• It is recommended to run Hyper-V on Windows Core (stripped down version with no GUI).  The core version will consume less resources, require less patches, etc.
• Server 2008 has “roles” that determine the functions on the server.  Hyper-V is recommended to be the only role on the server for production
• Hyper-V does not share memory pages
• Hyper-V has quick migration instead of VMotion.  Instead of a live migration, the machine is suspend and resumed on another host.  The amount of memory will have a direct impact on the amount of time required because the memory contents will written to the disk and then read from the disk on the new host.
• Hyper-V relies on Microsoft Clustering Services right now to provide multiple host functionality for SAN connected virtual machines.  This means that Enterprise Edition is the minimum required OS level for the host to perform Quick Migrations
• It is recommended that each LUN contain only one VM.  Space needed will be disk space required + virtual RAM assigned to the machine (for quick migrations) + room for snapshots of the virtual machine
• Live Backups of a VM are supported through VSS if the guest OS is VSS aware
• Virtual Hard Disk files are .vhd files instead .vmdk files for ESX
• Raw Device Mapping (RDM) in ESX is called Pass Through Disks in Hyper-V

At the end of the session we briefly covered the Microsoft Enterprise Management Product (think Virtual Center).  It is part of Microsoft System Center and is called SCVMM (System Center Virtual Machine Manager).  Here are some points for this product.

• Since Distributed Resource Scheduling doesn’t exist today for Hyper-V, they support the idea of Intelligent Placement of a VM onto the farm.  This data is configurable but the SCVMM basically tracks performance of the hosts over a recent time period in an attempt to recommend the best placement of the new virtual machine on a host.
• The entire product is driven by Windows Power Shell and is completely customizable, exportable, etc.
• Upcoming version of the product will support ESX and well as Hyper-V.  In order to support ESX, an existing Virtual Center will be required for SCVMM to interface.  (Think single pane of glass for management).  I have my doubts on this one but I’m curious.
• Self Service Portal – End Users will be able to provision their own machines.  Again, I’d have to see this one.

bron: http://www.bladevault.info

Whitepaper: VMware ESX Security Technical Implementation Guide

The need for security the virtualization hosts is growing.
In the last year several key entities released a series of guides and tools to help the customers in hardening the virtual infrastructures. Here some examples:

• In February 2007 VMware released a 19-pages security guide for VI 3.x
• In October 2007 the Center for Information Security (CIS) released a 70-pages security guide for ESX 3.x hosts
• In June 2008 Tripwire released a free configuration manager tool for ESX hosts, developed in collaboration with VMware

Since April 2008 the US Department of Defense can be added to this list, with a new 100-pages security guide which covers almost every aspect of VI 3.5 implementation.

Upgrading to ESX 3.5 and VirtualCenter 2.5 Best Practices

The following are best practice procedures when upgrading to VirtualCenter 2.5 and ESX Server 3.5:

To be done on VirtualCenter:

1. Backup your VirtualCenter database. VMware recommends detaching the database and copying it to somewhere safe.
2. Grant the System DSN user of the VirtualCenter Database db_owner privileges on the MSDB database as well as the VirtualCenter database.
3. Ensure that your ODBC System DSN is using the proper driver. You must have a SQL Server driver if your database is SQL 2000, and SQL Native Client driver if using SQL 2005.
4. Log in to your VirtualCenter server with a local Administrator account on your Windows system to run the installation, do not use a domain administrator or a domain account.
5. Perform the upgrade to VirtualCenter to 2.5 and ensure all your data is visible in VirtualCenter 2.5 after the upgrade.
6. Ensure no processes are running that conflict with the ports that VirtualCenter uses, such as IIS.
   

To be done on ESX Server host:

1. If there is a SAN connected to your ESX Server host detach the SAN before continuing with the upgrade.
2. Confirm that all the virtual machines are now migrated from the ESX Server host or powered down, and that ESX Server host is no longer part of an VMware High Availability or DRS cluster.
3. Download the newest version of the ESX operating system ISO image and burn it to CD.
4. Place the CD in the CD-ROM drive of the host and boot from the CD.
5. Install ESX Server 3.5 with a fresh install or upgrade.
   

Note: A fresh install wipes out all previous network configuration.

Sanbarrow’s VMware-liveCD

Ulli Hankeln over at Sanbarrow created a new version of the VMware-liveCD this version contains:

-Workstation 6.0.2 ripped
-Converter 3.0.3 cold clone mode
-ViClient for ESX 3.5.0 u1
-RemoteCli
-Virtual Disk Developement Kit
-ViToolkit for Powershell

The complete build is about 450 MB – it requires a box with at least 512 MB RAM to load the dotnet2 apps. Latest MOA 2.3.-011 now allows to run ESX 35i in WS 6.5. beta 91182. In this case the ESX 35i is running from the LiveCD – you can of course mount any local VMFS-volumes and assign them to the ESX 35i. Obviously you need a fat machine to run this LiveCD Of course it still works as a simple Cold Clone CD .

ESX 3.5 start vm’s inside workstation 6.5 beta1

additional note:
3.5i build 82664 works for me too – i can start VMs …essential entries I used for 3.5.i :

config.version = “8″
deploymentPlatform = “windows”
displayName = “esx35i”
ethernet0.present = “TRUE”
ethernet0.virtualdev = “e1000″
floppy0.present = “FALSE”
guestOS = “other”
ide1:0.autodetect = “TRUE”
ide1:0.deviceType = “cdrom-image”
ide1:0.fileName = “G:\esx35\esx-3.5.0-64607.iso”
ide1:0.present = “TRUE”
memsize = “1024″
monitor.virtual_exec = “hardware”
monitor_control.restrict_backdoor = “true”
numvcpus = “1″
scsi0.present = “TRUE”
scsi0.virtualDev = “lsilogic”
scsi0:0.fileName = “esx35i-system.vmdk”
scsi0:0.present = “TRUE”
sound.present = “FALSE”
virtualHW.version = “6″

Bron: ntpro.nl

Undocumented VCB config.js feature

Duncan over at YellowBricks.com found a undocumented fearure in the VCB config.js file

One of my customers wanted to use the default VCB framework but did not want to quiesce the VM for several reasons. (Databases, Active Directory etc.) I could not find an option in the config.js file but noticed the following in the file glue.js:

// A fallback to be able to switch to non-quiesced snapshots
if (typeof(NO_QUIESCE) != "undefined") {
cmd +="-Q 0 ";
}

In other words, setting the option “NO_QUIESCE” with no value in config.js results in the VM not being quiesced, default it will quiesce the VM! I added the following line to the  config.js file to accomplish this:

NO_QUIESCE=””;

Troubleshooting VMware(ESX) snapshots

Virtualization administrators can use snapshots on VMware ESX to travel back in time and figure out what went wrong with their virtual machines (VMs). But what do you do when your snapshots start acting funny? In this tip, we’ll troubleshoot potential problems that may come up when using snapshots on ESX.

Locating VMs that have snapshots
Trying to find out which VMs have snapshots can be challenging. There is no centralized way to do this built into the VMware Infrastructure Client or VirtualCenter, so you should periodically check your ESX servers for old snapshots that need to be deleted. There are a few methods you can use to accomplish this.

Method 1 – use the Find command on the Service Console

1. Login to service console.
2. Change to your /vmfs/volumes/ directory.
3. Type find -iname “*-delta.vmdk” -mtime +7 -ls to find snapshot files that have not been modified in 7 days or simply find -iname “*-delta.vmdk” to find all snapshot files.

Method 2 – Use a free Perl script from Dominic Rivera called Snapalert. This script uses the VI Perl toolkit to talk directly to VirtualCenter and makes sure that no components need to be installed on each host (also works with ESXi Installable). Optionally, the script can also generate an email report.

Method 3 – Use a free utility from Xtravirt called Snaphunter, which can report back on the snaphot status of VMs from multiple ESX Servers and also send email reports.

Method 4 – Query the VirtualCenter SQL database. VirtualCenter keeps track of all the snapshots on every host in its VPX_SNAPSHOT table. I’ve written a Visual Basic Script (VBS) that queries this table to display a list of VMs with running snapshots. This method works okay. But it relies on database tables, which could potentially change in future versions of VirtualCenter.

Dealing with snapshots that do not delete properly
Occasionally, a snapshot will not delete properly leaving an active snapshot for a VM. This can happen when using VMware Consolidated Backup or when deleting snapshots through Snapshot Manager. In most cases, the snapshot will not appear in the Snapshot Manager for you to delete. The only indication that a snapshot may still exist is the presence of delta files in the VM’s directory.

If you do have a snapshot running that is not in Snapshot Manager, you can attempt to delete it one of two ways. First, create a new snapshot using the VI Client and delete all snapshots from the snapshot manager after the new one has been created. Alternatively, login to the ESX Service Console, switch to the VM’s home directory and create a new snapshot by typing vmware-cmd createsnapshot . Wait for the snapshot to be created and type vmware-cmd removesnapshots. When it completes, check to see if the delta files have been deleted. If they have, then it was successfully completed.

If the delta files weren’t deleted, check the vmx file for the VM and locate the lines starting with scsi. If the VM is configured with only one virtual disk, it is usually scsi0:0 (if .present is false, it is a non-existent drive that you can ignore). The .fileName should be using the original disk file that was created with the VM and is usually the same name as your VM. If this is the case, then your VM is not using the snapshot files. If it has a -00000# in the filename, it is currently using a snapshot file. The following makes this a little clearer: VM with no snapshots: scsi0:0.present = "true" scsi0:0.fileName = "myvmname.vmdk" VM with snapshots: scsi0:0.present = "true" scsi0:0.fileName = "myvmname-000001.vmdk"

If this is the case and the above operation failed, your only other option is to either clone the VM or clone the VM’s disk file. To clone the VM you can use VMware Converter to create a new clone of your existing VM and, when completed, shutdown and delete the old VM.

Another method is to shutdown the VM, login to the Service Console, switch to the VM’s directory and clone the VM’s disk file by using vmkfstools and specifying the snapshot file as the source disk, i.e. “vmkfstools –i myvmname-000001.vmdk myvmnamenew.vmdk” Once it completes go into the settings for the VM, remove (don’t delete) the hard disk, add a new hard disk and browse to the newly created disk file. Power on the VM and verify everything is working before you delete the old disk and delta files.

Changing snapshot file locations
By default, the snapshots are written to the home directory of each virtual machine. Sometimes you may want to change this to not take up space on the volume of which your VM resides. It is possible to individually specify a new working directory for snapshots on each VM. Both snapshots and vswp files are written to this directory when you do this.

Be warned, though. If your VM is on shared storage and you specify local storage as a location you will not be able to use features like VMotion/HA/DRS. To do this follow these steps:

1. Power off your VM and login to the Service Console.
2. Edit the VMX file of your VM with Nano or Vi
3. Add a new line using the following syntax: workingDir = “/vmfs/volumes/SnapVolume/Snapshots/”
4. If you want your vswp file to stay in the VM’s directory, add the following line to the VMX file: sched.swap.dir = “/vmfs/volumes/VM-Volume1/MyVM/”. This step is optional. Furthermore, you do not need to worry about updating the existing “sched.swap.derivedName” parameter because it is generated by the VM and written to the config file each time the VM powers on.
5. Power on your VM and your vswp, vmsn and snapshot (delta-vmdk) files will now be located in this directory

Using VMotion with snapshots:
If you try to VMotion a VM with running snapshots from one host to another you will receive the following warning: “Reverting to snapshot would generate error (warnings) on the destination host.” This simply warns that if you have changed the default locations for any files of the VM (like snapshot or vswp files as detailed above), the VM will crash when the migration is complete. This is true if the destination host cannot access the same storage that the files are located on as the source host.

So if your VM was on shared storage and configured so that the snapshot files were on local storage, then you would have a problem if you VMotioned the VM to another host. If your VM has all its files on shared storage, and that storage is accessible to all ESX hosts then you’re in good shape. VMware recommends that you commit all snapshots before VMotioning VMs. But if you do not do this, it will work just fine.

Bron: searchvmware.techtarget.com