Thursday, July 29, 2010

Understanding the files that make up a VMware virtual machine

Understanding the files that make up virtual machine (VM) can ease management tasks, enabling you to clean up unnecessary files and more. In this tip, we will cover the components that make up a VM on an ESX host. In part one, we broke down virtual machines (VMs) is from a hardware perspective. In this tip we will cover the components
that make up a VM on an ESX host. These are the various files associated with a VM,
located in the VM's directory on the host (represented in the illustration below).


If you take a look at a VM's home directory on an ESX host using a file browser application like WinSCP or the datastore browser that is built into the VMware Infrastructure Client (VI Client), you will see a list of files that are associated with the VM. Most of the files start with the actual name of the VM and have different file extensions based on the type of file that it is. You may not see all of the possible file types until your VM is in a certain state. For example, the .vswp file is only present when the VM is powered on and the .vmss file is only present when a VM is suspended. Below is a typical VM directory listing using WinSCP.


So what are all these files that make up a virtual machine and what are they used for? Let's cover each file type in detail.
The .nvram file. This small file contains the Phoenix BIOS that is used as part of the boot process of the virtual machine. It is similar to a physical server that has a BIOS chip that lets you set hardware configuration options. A VM also has a virtual BIOS that is contained in the NVRAM file. The BIOS can be accessed when a VM first starts up by pressing the F2 key. Whatever changes are made to the hardware configuration of the VM are then saved in the NVRAM file. This file is in binary format and if deleted it will be automatically re-created when a VM is powered on.
The .vmx file. This file contains all of the configuration information and hardware settings of the virtual machine. Whenever you edit the settings of a virtual machine, all of that information is stored in text format in this file. This file can contain a wide variety of information about the VM, including its specific hardware configuration (i.e., RAM size, network interface card info, hard drive info and serial/parallel port info), advanced power and resource settings, VMware tools options, and power management options. While you can edit this file directly to make changes to a VM's configuration it is not recommended that you do so unless you know what you are doing. If you do make changes directly to this file, it's a very good idea to make a backup copy of this file first.
VMDK files. All virtual disks are made up of two files, a large data file equal to the size of the virtual disk and a small text disk descriptor file, which describes the size and geometry of the virtual disk file. The descriptor file also contains a pointer to the large data file as well as information on the virtual disks drive sectors, heads, cylinders and disk adapter type. In most cases these files will have the same name as the data file that it is associated with (i.e., myvm_1.vmdk and myvm_1-flat.vmdk). You can match the descriptor file to the data file by checking the Extent Description field in this file to see which –flat, -rdm or –delta file is linked to it. An example disk descriptor file is shown below:
 The three different types of virtual disk data files that can be used with virtual machines are covered below:
The –flat.vmdk file
This is the default large virtual disk data file that is created when you add a virtual hard drive to your VM that is not an RDM. When using thick disks, this file will be approximately the same size as what you specify when you create your virtual hard drive. One of these files is created for each virtual hard drive that a VM has configured, as shown in the examples below.


The –delta.vmdk file
These virtual disk data files are only used when snapshots are created of a virtual machine. When a snapshot is created, all writes to the original –flat.vmdk are halted and it becomes read-only; changes to the virtual disk are then written to these –delta files instead. The initial size of these files is 16 MB and they are grown as needed in 16 MB increments as changes are made to the VM's virtual hard disk. Because these files are a bitmap of the changes made to a virtual disk, a single –delta.vmdk file cannot exceed the size of the original –flat.vmdk file. A delta file will be created for each snapshot that you create for a VM and their file names will be incremented numerically (i.e., myvm-000001-delta.vmdk, myvm-000002-delta.vmdk). These files are automatically deleted when the snapshot is deleted after they are merged back into the original –flat.vmdk file.

The -rdm.vmdk file
This is the mapping file for the RDM that manages mapping data for the RDM device. The mapping file is presented to the ESX host as an ordinary disk file, available for the usual file system operations. However, to the virtual machine the storage virtualization layer presents the mapped device as a virtual SCSI device. The metadata in the mapping file includes the location of the mapped device (name resolution) and the locking state of the mapped device. If you do a directory listing you will see that these files will appear to take up the same amount of disk space on the VMFS volume as the actual size of the LUN that it is mapped to, but in reality they just appear that way and their size is very small. One of these files is created for each RDM that is created on a VM.

The .vswp file. When you power on a VM, a memory swap file is created that can be used in lieu of physical host memory if an ESX host exhausts all of its physical memory because it is overcommitted. These files are created equal in size to the amount of memory assigned to a VM, minus any memory reservations (default is 0) that a VM may have set on it (i.e., a 4 GB VM with a 1 GB reservation will have a 3 GB vswp file created). These files are always created for virtual machines but only used if a host exhausts all of its physical memory. As virtual machine memory that is read/written to disk is not as fast as physical host RAM, your VMs will have degraded performance if they do start using this file. These files can take up quite a large amount of disk space on your VMFS volumes, so ensure that you have adequate space available for them, as a VM will not power on if there is not enough room to create this file. These files are deleted when a VM is powered off or suspended.

The .vmss file. This file is used when virtual machines are suspended and is used to preserve the memory contents of the VM so it can start up again where it left off. This file will be approximately the same size as the amount of RAM that is assigned to a VM (even empty memory contents are written). When a VM is brought out of a suspend state, the contents of this file are written back into the physical memory of a host server, however the file is not automatically deleted until a VM is powered off (an OS reboot won't work). If a previous suspend file exists when a VM is suspended again, this file is re-used instead of deleted and re-created. If this file is deleted while the VM is suspended, then the VM will start normally and not from a suspended state.

The .vmsd file. This file is used with snapshots to store metadata and other information about each snapshot that is active on a VM. This text file is initially 0 bytes in size until a snapshot is created and is updated with information every time snapshots are created or deleted. Only one of these files exists regardless of the number of snapshots running, as they all update this single file. The snapshot information in this file consists of the name of the VMDK and vmsn file used by each snapshot, the display name and description, and the UID of the snapshot. Once your snapshots are all deleted this file retains old snapshot information but increments the snapshot UID to be used with new snapshots. It also renames the first snapshot to "Consolidate Helper," presumably to be used with consolidated backups.

The .vmsn file. This file is used with snapshots to store the state of a virtual machine when a snapshot is taken. A separate .vmsn file is created for every snapshot that is created on a VM and is automatically deleted when the snapshot is deleted. The size of this file will vary based on whether or not you choose to include the VM's memory state with your snapshot. If you do choose to store the memory state, this file will be slightly larger than the amount of RAM that has been assigned to the VM, as the entire memory contents, including empty memory, is copied to this file. If you do not choose to store the memory state of the snapshot then this file will be fairly small (under 32 KB). This file is similar in nature to the .vmss that is used when VMs are suspended.

The .log file. These are the files that are created to log information about the virtual machine and are oftentimes used for troubleshooting purposes. There will be a number of these files present in a VM's directory. The current log file is always named vmware.log and up to six older log files will also be retained with a number at the end of their names (i.e., vmware-2.log). A new log file is created either when a VM is powered off and back on or if the log file reaches the maximum defined size limit. The amount of log files that are retained and the maximum size limits are both defined as VM advanced configuration parameters (log.rotateSize and log.keepOld).

The .vmxf file. This file is a supplemental configuration file that is not used with ESX but is retained for compatibility purposes with Workstation. It is in text format and is used by Workstation for VM teaming where multiple VMs can be assigned to a team so they can be powered on or off, or suspended and resumed as a single object.
That covers all the files that are associated with a virtual machine, and after reading this tip you should have a better understanding of the anatomy of a virtual machine. Now you can check out the VMs on your own ESX hosts and see the various files that make up your virtual machines. You might find a few surprises from old data that has not been properly cleaned up on your VMFS volumes. Just be careful before you start deleting any files and make sure that the files you delete are no longer needed and not being used.

Wednesday, July 28, 2010

Choosing a block size when creating VMFS datastores

When you create a VMFS datastore on your VMware ESX servers many administrators select the default 1MB block size without knowing when or why to change it. The block size determines the minimum amount of disk space that any file will take up on VMFS datastores. So an 18KB log file will actually take up 1MB of disk space (1 block) and a 1.3MB file will take up 2MB of disk space (2 blocks). But the block size also determines the maximum size that any file can be, if you select a 1MB block size on your data store the maximum file size is limited to 256GB. So when you create a VM you cannot assign it a single virtual disk greater then 256GB. There is also no way to change the block size after you set it without deleting the datastore and re-creating it, which will wipe out any data on the datastore.


Because of this you should choose your block size carefully when creating VMFS datastores. The VMFS datastores mainly contain larger virtual disk files so increasing the block size will not use all that much more disk space over the default 1MB size. You have the following choices when creating a datastore:
• 1MB block size – 256GB maximum file size
• 2MB block size – 512GB maximum file size
• 4MB block size – 1024GB maximum file size
• 8MB block size – 2048GB maximum file size



Besides having smaller files use slightly more disk space on your datastore there are no other downsides to using larger block sizes. There is no noticeable I/O performance difference by using a larger block size. When you create your datastore, make sure you choose your block size carefully. 1MB should be fine if you have a smaller datastore (less than 500GB) and never plan on using virtual disks greater then 256GB. If you have a medium (500GB – 1TB) datastore and there is a chance that you may need a VM with a larger disk then go with a 2MB or 4MB block size. For larger datastores (1TB – 2TB) go with a 4MB or 8MB block size. In most cases you will not be creating virtual disks equal to the maximum size of your datastore (2TB) so you will usually not need a 8MB block size.


So remember, choose carefully, once you create your datastore there is no changing it later

CONFIGURING SAMBA ON LINUX FOR Active Directory


CONFIGURING SAMBA ON LINUX FOR Active Directory
PREREQUISITE
Ø  Samba package should be preinstalled if not then you have to install samba 3.0 before configuring samba for Active Directory.
PROCEDURE
1.       Make backup copy of /etc/sab.conf
2.       Open /etc/smb.conf in text editor
3.       Change the entry “workgroup” to your desired domain name

4.       Change “netbios name ” entry to your domain controller host name as shown below

5.       Remove  ‘;’ from the beginning of the line “hosts allow” and add your network .

6.       Now go to “Security” line in “Domain member option” section remove “;” and change the line to below as show in screen

7.       Go to “realm” line and remove “;” from beginning of line and change the line as shown below

8.       In password server line give ip address of your domain controller

9.       Save the file and exit
10.    Restart the SMB and Network Service by issuing following commands 

11.   Now join the Linux to AD domain using following command
·         net ads join –U Administrator.
·         If connection is successful it will prompt password for Administrator




Tuesday, July 27, 2010

How to Reset root password for ESX

1.0 Introduction

This post provides information on how to reset the Root password in VMware ESX 4.
Without the root password it is impossible to carry out certain tasks. Even logged on with a non-root account, without knowing it you won’t be able to elevate privileges and adequately manage the server.

2.0 Pre-Requisites

If the ESX server is part of a cluster, vMotion your VM’s off the host then power down the ESX host. If the ESX server is standalone, power off running VM’s and then shut down the ESX host.
Access to the physical ESX server console – a remote network session cannot be used.

3.0 Resolution – Resetting the Root password
A lost root password cannot be recovered, but as outlined in the procedure below, it can be reset.

1.       Power on the ESX server. At the Grub boot loader, select the “VMware ESX 4.0” entry and press a to modify the kernel argument


2.       The default kernel options for the “VMware ESX 4.0” entry will be displayed.

3.       Add a space and the word single to the end of the list of arguments and press Enter. (Note that the first few arguments will scroll off the left hand side of the console.)

4.       ESX will boot to single user mode. This may take a minute or so and when complete, a sh-32.# prompt will appear.


5.       At the prompt, type the command passwd and press Enter. Follow the prompts and enter the required new root password twice. A successful password change will result in the display of a “passwd: all authentication tokens updated successfully” message.



6.       Enter the command reboot and press Enter. ESX will boot normally.

7.       When ESX has finished booting, switch to the ESX console by pressing Alt-F1 and confirm the new password has taken affect by logging on as root.


References

Friday, July 23, 2010

ESXi 4.1 - Major Security Issue

On Thursday July 15th, a user raised a question on the VMTN forums regarding an ESXi 4.1 password issue. The problem was described as the following:

Hi all
It seems that authentication only requires the first 8 characters to be correct. My root password is 11 characters long, but so long as the first 8 characters are correct, I can put whatever I like after that and it still authenticates me. Tested this on three ESXi boxes, all running 260247 (release)

I performed a few quick tests to validate the user's claim and in fact this was the case with a new installation of ESXi 4.1

CLI Access for ESXi 4.0

1.    Alt-F1 (Note: As pointed out below, you will not see your typing on this screen, just trust us, it is there).

2.    Type :- unsupported

3.    Enter root password

4.    vi /etc/inetd.conf

5.    delete the “#” from ssh

6.    services.sh restart

VMware ESX and ESXi 4.1 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 manage 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. VMware has created APIs through which monitoring and management tasks – traditionally done through Service Console agents – can be performed. VMware has provided remote scripting environments such as vCLI and PowerCLI to allow the remote execution of scripts and commands.

Tech Support Mode (TSM) provides a command-line interface that can be used by the administrator to troubleshoot and correct abnormal conditions on VMware ESXi hosts.
CLI-Based Configuration
VMware ESX Service Console has a host CLI through which VMware ESX can be configured. VMware ESX can also be configured using vSphere CLI (vCLI) or vSphere PowerCLI.
The vSphere CLI (vCLI) is a remote scripting environment that interacts with VMware ESXi hosts to enable host configuration through scripts or specific commands. It replicates nearly all the equivalent COS commands for configuring ESX.

VMware vSphere PowerCLI is a robust command-line tool for automathing all aspect of vSphere management, including host, network, storage, virtual machine, guest operating system, and more.

Notes:  
  • vCLIPowerCLI, and vSphere SDk for Perl are limited to read-only access for the free vSphere Hypervisor edition. To enable full functionality of vCLI on a VMware ESXi host, the host must be licensed with vSphere Essentials, vSphere Essential Plus, vSphere Standard, vSphere Advanced, vSphere Enterprise, or vSphere Enterprise Plus.  
  • Certain COS commands have not been implemented in the vCLI because they pertain to the management of the COS itself and not ESXi. For details, please see the vSphere Command-Line Interface Documentation.
Scriptable Installation
VMware ESX supports scriptable installations through utilities like KickStart.
VMware ESXi supports scriptable installations using a mechanism similar to Kickstart, and includes the ability to run pre- and post-installation scripts.  VMware ESXi also provides support for post installation configuration using PowerCLI- and vCLI-based configuration scripts.
Boot from SAN
VMware ESX supports boot from SAN. Booting from SAN requires one dedicated LUN per server.
VMware ESXi may be booted from SAN. This is supported for Fibre Channel SAN, as well as iSCSI and FCoE for certain storage adapters that have been qualified for this capability. Please check the Hardware Compatibility List for supported storage adapters.
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 with vSphere Essentials, vSphere Essential Plus, vSphere Standard, vSphere Advanced, vSphere Enterprise, or vSphere Enterprise Plus.

The free vSphere Hypervisor edition does not support SNMP.
Active Directory Integration
VMware ESX provides native support for Active Directory integration.
VMware ESXi provides native support for Active Directory integration.
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 include their own proprietary CIM Providers in customized versions of VMware ESXi. These customized versions are available either from VMware’s web site or the partner’s web site, depending on the partner.
Remote console applications like Dell DRAC, HP iLO, IBM RSA, and FSC iRMC S2are supported with ESXi.
Software Patches and Updates
VMware ESX software patches and upgrades behave like traditional Linux based patches and upgrades. The installation of asoftware 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. Furthermore, third party components such as OEM CIM providers can be updated independently of the base ESXi component, and vice versa.
vSphere Web Access
vSphere Web Access is only experimentally supported in VMware ESX.
VMware ESXi does not support web access at this time.
Licensing
For licensing information, see theVMware Sphere Editions Comparison.
For licensing information, see theVMware Sphere Editions Comparison.
Diagnostics and Troubleshooting
VMware ESX Service Console can be used to issue command that can help diagnose and repair support issues with the server.
VMware ESXi has several ways to enable support of the product:
  • Remote command sets such as the vCLI include diagnostic commands such as vmkfstools, resxtop, and vmware-cmd.
  • The console interface of VMware ESXi (known as the DCUI or Direct Console User Interface) has functionality to help repair the system, including restarting of all management agents.
  • Tech Support Mode, which allows low-level access to the system so that advanced diagnostic commands can be issues. For more information, seeUsing Tech Support in ESXi 4.1 (1017910).
Jumbo Frames
VMware ESX 4.1 fully supports Jumbo Frames.

VMware ESXi 4.1 fully supports Jumbo Frames


List of Known Issues vSphere 4.1

The known issues are grouped as follows:
•             Installation Issues
•             Upgrade Issues
•             Networking Issues
•             Storage Issues
•             Server Configuration Issues
•             vCenter and vSphere Client Issues
•             Migration Issues
•             VMware HA and Fault Tolerance Issues
•             Guest Operating System Issues
•             Supported Hardware Issues
•             Internationalization Issues
•             vSphere Command-Line Interface Issues
•             Miscellaneous Issues

What's New in vSphere 4.1

With this release, the VMware virtual datacenter operating system continues to transform x86 IT infrastructure into the most efficient, shared, on-demand utility, with built-in availability, scalability, and security services for all applications and simple, proactive automated management. The new and enhanced features in vSphere 4.1 are listed below.


• Installation and Deployment

• Storage

• Network

• Availability

• Management

• Platform Enhancements

• Partner Ecosystem

For Details Click Here
 
http://www.vmware.com/support/vsphere4/doc/vsp_41_new_feat.html

Monday, July 19, 2010

NFS Storage Configuration for vSphere using Windows 2008

Windows 2008 introduced the ability to use NFS shares, enabling the server to be used as a storage target.
This Xtravirt white paper is a step by step guide of the process to setup and host NFS shares on a Windows 2008 server and connection to an ESXi 4 host. This can be used with a VI in a Boxsolution.The scenario described assumes that this is being setup on a single server which includes Domain Controller functions. It is designed for personal testing only and not an advocation as a production solution.
Key Concepts:
·         Install and configuration of Service for Network File System
·         Install and configuration of Identity Management for UNIX
·         Adding NFS storage to an ESX host
References
1. Mastering VMware vSphere 4 (Computer/Tech)Description: http://www.assoc-amazon.com/e/ir?t=professi00-20&l=btl&camp=213689&creative=392969&o=1&a=0470481382

2. VMware vSphere 4 Administration Instant ReferenceDescription: http://www.assoc-amazon.com/e/ir?t=professi00-20&l=btl&camp=213689&creative=392969&o=1&a=0470520728

vCenter Mobile Access (vCMA)

VMware vCenter Mobile Access (vCMA).  vCMA allows you to monitor and manage VMware Infrastructure from your mobile phone with an interface that is optimized for such devices. Specifically, it allows you to:
  • Search for virtual machines in your data center
  • Migrate virtual machines from one host to another using vMotion
  • Execute recovery plans using VMware Site Recovery Manager
  • Access Scheduled Tasks, Alarms and Events
  • And much more
In order for you to access vCMA, you will need to deploy a virtual appliance; call it the vCMA server.  The vCMA server must be connected to VMware vCenter or any of the ESX servers that you want to manage.  Once the server component is set up, you can manage your datacenter from the convenience of your mobile phone.




Saturday, July 17, 2010

How to Convert a WIM File to an ISO File

Introduction


The WIM (Windows Imaging) format is a compression format used in versions of Microsoft Windows from Vista onward. The format allows compression to disc images similar to the ISO format. While there are a few differences between the formats, it is possible to create an ISO image containing the contents of the WIM image. WIM images are engineered to perform optimally in Windows systems, but conversion to ISO will render the image more portable

Instructions

Things you would need:

·         Computer with Internet access running Microsoft Windows Vista or later
·         WIM image file
·         Writable CD or DVD

1.       Download the Windows Automated Installation kit from microsoft.com/downloads/. While the file downloads, ensure that the WIM file from which you wish to make an ISO is located in the root c:/ directory. (Name it discovery.wim for ease of use.) When the Windows Automated Installation has downloaded, follow the prompts to install the software.
2.       Open the Deployment Tools Command Prompt  Open the Start Menu in Microsoft Windows and click "All Programs" then "Microsoft Windows AIK". The Command Prompt is in this folder.
3.       Open a Windows Preinstallation Environment and copy the WIM file into it; do so by typing "CopyPE C:\Winpe" to create the environment, then "Copy /y c:\discover.wim c:\Winpe\ISO\Sources" to copy the file into the environment.
4.       Navigate back into the PETools folder by typing "Cd C:\Program Files\Windows AIK\Tools\PETools".
5.       Type "Oscdimg -n -bc:\winpe\ISO\boot\etfsboot.com c:\winpe\ISO c:\.iso" to create an ISO image from the contents of the Preinstallation Environment (your WIM file).

Alternatively, if the WIM image to be converted to ISO is larger than a standard CD (700 MB), type "Oscdimg -m -bc:\winpe\ISO\boot\etfsboot.com c:\winpe\ISO c:\winpe.iso" at Step 4.
6.       Make a disc from your ISO image using a utility that can burn CD or DVD media.

How to manually extend the activation grade period on expiring for Server 2008

When the 60-day activation grace period is about to expire and end, run the slmgr.vbs script to reset and extend the evaluation period for another new 60-day trial evaluation period, with everything including programs installed and data intact.
  1. Open an elevated command prompt.
  2. Type the slmgr.vbs -rearm, and then press Enter to reset the activation grace period to 60 days.
  3. Restart the computer.
To check the status or time that is left on current activation grace period or evaluation period, run slmgr.vbs -dli command to display the number of days that are left in the current 60-day evaluation period.
References