Ever since VMware was founded in 1998, it has been creating stable x86 virtualization platforms that allow multiple guest operating systems and applications to run on a single physical server. Before an administrator can begin creating and configuring vSphere virtual machines, it is important to understand what a virtual machine is and the concepts behind virtualizing hardware.
In this chapter, you will learn:
What a virtual machine is
Components of a virtual machine
Why to use virtual machines
Files that make up a virtual machine
The four primary resources
The multiple instances of Windows or Linux systems that are running on an ESXi host are commonly referred to as a virtual machine (VM). Any reference to a guest operating system (OS) is an instance of Linux, Windows, or any other supported operating system that is installed on the VM.
At the heart of virtualization lies the virtual machine. A virtual machine is a set of virtual hardware whose characteristics are determined by a set of files; it is this virtual hardware that a guest operating system is installed on. A virtual machine runs an operating system and a set of applications just like a physical server. A virtual machine comprises a set of configuration files and is backed by the physical resources of an ESXi host. An ESXi host is the physical server that has the VMware hypervisor, known as ESXi, installed. Each virtual machine is equipped with virtual hardware and devices that provide the same functionality as having physical hardware.
Virtual machines are created within a virtualization layer, such as ESXi running on a physical server. This virtualization layer manages requests from the virtual machine for resources such as CPU or memory. It is the virtualization layer that is responsible for translating these requests to the underlying physical hardware.
Each virtual machine is granted a portion of the physical hardware. All VMs have their own virtual hardware (there are important ones to note, called the primary 4: CPU, memory, disk, and network). Each of these VMs is isolated from the other and each interacts with the underlying hardware through a thin software layer known as the hypervisor. This is different from a physical architecture in which the installed operating system interacts with installed hardware directly.
With virtualization, there are many benefits, in relation to portability, security, and manageability that aren't available in an environment that uses a traditional physical infrastructure. However, once provisioned, virtual machines use many of the same principles that are applied to physical servers.
The preceding diagram demonstrates the differences between the traditional physical architecture (left) and a virtual architecture (right). Notice that the physical architecture typically has a single application and a single operating system using the physical resources. The virtual architecture has multiple virtual machines running on a single physical server, accessing the hardware through the thin hypervisor layer.
When a virtual machine is created, a default set of virtual hardware is assigned to it. VMware provides devices and resources that can be added and configured to the virtual machine. Not all virtual hardware devices will be available to every single virtual machine; both the physical hardware of the ESXi host and the VM's guest OS must support these configurations. For example, a virtual machine will not be capable of being configured with more vCPUs than the ESXi host has logical CPU cores.
The options and configurations for these devices will be explained further in Chapter 2, Creating a Virtual Machine Using the Wizard. For example, we'll explore the effects of assigning virtual sockets versus that of assigning virtual cores on the virtual machine's vCPU.
The virtual hardware available includes:
DVD/CD-ROM: NEC VMware IDE CDR10 that is installed by default in new virtual machines created in vSphere. The DVD/CD-ROM can be configured to connect to the client workstation DVD/CD-ROM, an ESXi host DVD/CD-ROM, or even an
.isofile located on a datastore. DVD/CD-ROM devices can be added to or removed from a virtual machine.
Floppy drive: This is installed by default with new virtual machines created in vSphere. The floppy drive can be configured to connect to the client device's floppy drive, a floppy device located on the ESXi host, or even a floppy image (
.flp) located on a datastore. Floppy devices can be added to or removed from a virtual machine.
Hard disk: This stores the guest operating system, program files, and any other data associated with a virtual machine. The virtual disk is a large file, or potentially a set of files, that can be easily copied, moved, and backed up.
IDE controller: Intel 82371 AB/EB PCI Bus Master IDE Controller that presents two Integrated Drive Electronics (IDE) interfaces to the virtual machine by default. This IDE controller is a standard way for storage devices, such as floppy drives and CD-ROM drives, to connect to the virtual machine.
Network adapter: ESXi networking features provide communication between virtual machines residing on the same ESXi host, between VMs residing on different ESXi hosts, and between VMs and physical machines. When configuring a VM, network adapters (NICs) can be added and the adapter type can be specified.
PCI controller: This is a bus located on the virtual machine motherboard, communicating with components such as a hard disk. A single PCI controller is presented to the virtual machine. This cannot be configured or removed.
PCI device: DirectPath devices can be added to a virtual machine. The devices must be reserved for PCI pass-through on the ESXi host that the virtual machine runs on. Keep in mind that snapshots are not supported with DirectPath I/O pass-through device configuration. For more information on virtual machine snapshots, see http://vmware.com/kb/1015180.
Processor: This specifies the number of sockets and core for the virtual processor. This will appear as AMD or Intel to the virtual machine guest operating system depending upon the physical hardware.
Serial port: This is an interface for connecting peripherals to the virtual machine. The virtual machine can be configured to connect to a physical serial port, a file on the host, or over the network. The serial port can also be used to establish a direct connection between two VMs. Virtual serial ports can be added to or removed from the virtual machine.
SCSI controller: This provides access to virtual disks. The virtual SCSI controller may appear as one of several different types of controllers to a virtual machine, depending on the guest operating system of the VM. Editing the VM configuration can modify the SCSI controller type, a SCSI controller can be added, and a virtual controller can be configured to allocate bus sharing.
SCSI device: A SCSI device interface is available to the virtual machine by default. This interface is a typical way to connect storage devices (hard drives, floppy drives, CD-ROMs, and so on) to a VM. SCSI device that can be added to or removed from a virtual machine.
SIO controller: The Super I/O controller provides serial and parallel ports, and floppy devices, and performs system management activities. A single SIO controller is presented to the virtual machine. This cannot be configured or removed.
VMCI: The Virtual Machine Communication Interface provides high-speed communication between the hypervisor and a virtual machine. VMCI can also be enabled for communication between VMs. VMCI devices cannot be added or removed.
In any infrastructure, there are many business processes that have applications supporting them. These applications typically have certain requirements, such as security or performance requirements, which may limit the application to being the only thing installed on a given machine. Without virtualization, there is typically a 1:1:1 ratio for server hardware to an operating system to a single application. This type of architecture is not flexible and is inefficient due to many applications using only a small percentage of the physical resources dedicated to it, effectively leaving the physical servers vastly underutilized. As hardware continues to get better and better, the gap between the abundant resources and the often small application requirements widens. Also, consider the overhead needed to support the entire infrastructure, such as power, cooling, cabling, manpower, and provisioning time. A large server sprawl will cost more money for space and power to keep these systems housed and cooled.
Virtual infrastructures are able to do more with less—fewer physical servers are needed due to higher consolidation ratios. Virtualization provides a safe way of putting more than one operating system (or virtual machine) on a single piece of server hardware by isolating each VM running on the ESXi host from any other. Migrating physical servers to virtual machines and consolidating onto far fewer physical servers means lowering monthly power and cooling costs in the datacenter. Fewer physical servers can help reduce the datacenter footprint; fewer servers means less networking equipment, fewer server racks, and eventually less datacenter floor space required. Virtualization changes the way a server is provisioned. Initially it took hours to build a cable and install the OS; now it takes only seconds to deploy a new virtual machine using templates and cloning.
VMware offers a number of advanced features that aren't found in a strictly physical infrastructure. These features, such as High Availability, Fault Tolerance, and Distributed Resource Scheduler, help with increased uptime and overall availability. These technologies keep the VMs running or give the ability to quickly recover from unplanned outages. The ability to quickly and easily relocate a VM from one ESXi host to another is one of the greatest benefits of using vSphere virtual machines.
In the end, virtualizing the infrastructure and using virtual machines will help save time, space, and money. However, keep in mind that there are some upfront costs to be aware of. Server hardware may need to be upgraded or new hardware purchased to ensure compliance with the VMware Hardware Compatibility List (HCL). Another cost that should be taken into account is the licensing costs for VMware and the guest operating system; each tier of licensing allows for more features but drives up the price to license all of the server hardware.
Virtualization decouples physical hardware from an operating system. Each virtual machine contains a set of its own virtual hardware and there are four primary resources that a virtual machine needs in order to correctly function. These are CPU, memory, network, and hard disk. These four resources look like physical hardware to the guest operating systems and applications. The virtual machine is granted access to a portion of the resources at creation and can be reconfigured at any time thereafter. If a virtual machine experiences constraint, one of the four primary resources is generally where a bottleneck will occur.
In a traditional architecture, the operating system interacts directly with the server's physical hardware without virtualization. It is the operating system that allocates memory to applications, schedules processes to run, reads from and writes to attached storage, and sends and receives data on the network. This is not the case with a virtualized architecture. The virtual machine guest operating system still does the aforementioned tasks, but also interacts with virtual hardware presented by the hypervisor.
In a virtualized environment, a virtual machine interacts with the physical hardware through a thin layer of software known as the virtualization layer or the hypervisor; in this case the hypervisor is ESXi. This hypervisor allows the VM to function with a degree of independence from underlying physical hardware. This independence is what allows vMotion and Storage vMotion functionality. The following diagram demonstrates a virtual machine and its four primary resources:
This section will provide an overview of each of the "primary four" resources. Configurations for these resources will be discussed in Chapter 2, Creating a Virtual Machine Using the Wizard and Chapter 4, Advanced Virtual Machine Settings.
The virtualization layer runs CPU instructions to make sure that the virtual machines run as though accessing the physical processor on the ESXi host. Performance is paramount for CPU virtualization, and therefore will use the ESXi host physical resources whenever possible. The following image displays a representation of a virtual machine's CPU:
A virtual machine can be configured with up to 64 virtual CPUs (vCPUs) as of vSphere 5.5. The maximum vCPUs able to be allocated depends on the underlying logical cores that the physical hardware has. Another factor in the maximum vCPUs is the tier of vSphere licensing; only Enterprise Plus licensing allows for 64 vCPUs. The VMkernel includes a CPU scheduler that dynamically schedules vCPUs on the ESXi host's physical processors.
The VMkernel scheduler, when making scheduling decisions, considers socket-core-thread topology. A socket is a single, integrated circuit package that has one or more physical processor cores. Each core has one or more logical processors, also known as threads. If hyperthreading is enabled on the host, then ESXi is capable of executing two threads, or sets of instruction, simultaneously. Effectively, hyperthreading provides more logical CPUs to ESXi on which vCPUs can be scheduled, providing more scheduler throughput. However, keep in mind that hyperthreading does not double the core's power. During times of CPU contention, when VMs are competing for resources, the VMkernel timeslices the physical processor across all virtual machines to ensure that the VMs run as if having a specified number of vCPUs.
VMware vSphere Virtual Symmetric Multiprocessing (SMP) is what allows the virtual machines to be configured with up to 64 virtual CPUs, which allows a larger CPU workload to run on an ESXi host. Though most supported guest operating systems are multiprocessor aware, many guest OSes and applications do not need and are not enhanced by having multiple vCPUs. Check vendor documentation for operating system and application requirements before configuring SMP virtual machines.
In a physical architecture, an operating system assumes that it owns all physical memory in the server, which is a correct assumption. A guest operating system in a virtual architecture also makes this assumption but it does not, in fact, own all of the physical memory. A guest operating system in a virtual machine uses a contiguous virtual address space that is created by ESXi as its configured memory. The following image displays a representation of a virtual machine's memory:
Virtual memory is a well-known technique that creates this contiguous virtual address space, allowing the hardware and operating system to handle the address translation between the physical and virtual address spaces. Since each virtual machine has its own contiguous virtual address space, this allows ESXi to run more than one virtual machine at the same time. The virtual machine's memory is protected against access from other virtual machines.
This effectively results in three layers of virtual memory in ESXi: physical memory, guest operating system physical memory, and guest operating system virtual memory. The VMkernel presents a portion of physical host memory to the virtual machine as its guest operating system physical memory. The guest operating system presents the virtual memory to the applications.
The virtual machine is configured with a set of memory; this is the sum that the guest OS is told it has available to it. A virtual machine will not necessarily use the entire memory size; it only uses what is needed at the time by the guest OS and applications. However, a VM cannot access more memory than the configured memory size. A default memory size is provided by vSphere when creating the virtual machine. It is important to know the memory needs of the application and guest operating system being virtualized so that the virtual machine's memory can be sized accordingly.
There are two key components with virtual networking: the virtual switch and virtual Ethernet adapters. A virtual machine can be configured with up to ten virtual Ethernet adapters, called vNICs. The following image displays a representation of a virtual machine's vNIC:
Virtual network switching is software interfacing between virtual machines at the vSwitch level until the frames hit an uplink or a physical adapter, exiting the ESXi host and entering the physical network. Virtual networks exist for virtual devices; all communication between the virtual machines and the external world (physical network) goes through vNetwork standard switches or vNetwork distributed switches.
Virtual networks operate on layer 2, data link, of the OSI model. A virtual switch is similar to a physical Ethernet switch in many ways. For example, virtual switches support the standard VLAN (802.1Q) implementation and have a forwarding table, like a physical switch. An ESXi host may contain more than one virtual switch. Each virtual switch is capable of binding multiple vmnics together in a network interface card (NIC) team, which offers greater availability to the virtual machines using the virtual switch.
There are two connection types available on a virtual switch: a port group and a VMkernel port. Virtual machines are connected to port groups on a virtual switch, allowing access to network resources. VMkernel ports provide a network service to the ESXi host to include IP storage, management, vMotion, and so on. Each VMkernel port must be configured with its own IP address and network mask. The port groups and VMkernel ports reside on a virtual switch and connect to the physical network through the physical Ethernet adapters known as vmnics. If uplinks (vmnics) are associated with a virtual switch, then the virtual machines connected to a port group on this virtual switch will be able to access the physical network.
In a non-virtualized environment, physical servers connect directly to storage, either to an external storage array or to their internal hard disk arrays to the server chassis. The issue with this configuration is that a single server expects total ownership of the physical device, tying an entire disk drive to one server. Sharing storage resources in non-virtualized environments can require complex filesystems and migration to file-based Network Attached Storage (NAS) or Storage Area Networks (SAN). The following image displays a representation of a virtual disk:
Shared storage is a foundational technology that allows many things to happen in a virtual environment (High Availability, Distributed Resource Scheduler, and so on). Virtual machines are encapsulated in a set of discrete files stored on a datastore. This encapsulation makes the VMs portable and easy to be cloned or backed up. For each virtual machine, there is a directory on the datastore that contains all of the VM's files. A datastore is a generic term for a container that holds files as well as
.iso images and floppy images. It can be formatted with VMware's Virtual Machine File System (VMFS) or can use NFS. Both datastore types can be accessed across multiple ESXi hosts.
VMFS is a high-performance, clustered filesystem devised for virtual machines that allows a virtualization-based architecture of multiple physical servers to read and write to the same storage simultaneously. VMFS is designed, constructed, and optimized for virtualization. The newest version, VMFS-5, exclusively uses 1 MB block size, which is good for large files, while also having an 8 KB subblock allocation for writing small files such as logs. VMFS-5 can have datastores as large as 64 TB. The ESXi hosts use a locking mechanism to prevent the other ESXi hosts accessing the same storage from writing to the VMs' files. This helps prevent corruption.
Several storage protocols can be used to access and interface with VMFS datastores; these include Fibre Channel, Fibre Channel over Ethernet, iSCSI, and direct attached storage. NFS can also be used to create a datastore. VMFS datastore can be dynamically expanded, allowing the growth of the shared storage pool with no downtime.
vSphere significantly simplifies accessing storage from the guest OS of the VM. The virtual hardware presented to the guest operating system includes a set of familiar SCSI and IDE controllers; this way the guest OS sees a simple physical disk attached via a common controller. Presenting a virtualized storage view to the virtual machine's guest OS has advantages such as expanded support and access, improved efficiency, and easier storage management.
vSphere administrators should know the components of virtual machines. There are multiple VMware file types that are associated with and make up a virtual machine. These files are located in the VM's directory on a datastore. The following table will summarize and provide a quick reference and short description of the files that make up a virtual machine:
Old log file entries
Let's explore these virtual machine files in more detail.
.vmx file describes the current configuration information and hardware settings for the VM. This can contain a large variety of information regarding the virtual machine, to include its specific virtual hardware configuration (amount of RAM, NIC settings, CD-ROM information, parallel/serial port information, and so on), as well as its advanced resource and power settings, VMware tools options, and so forth. It is possible to make changes and directly edit this file; however, do this at your own risk. Generally, it is recommended to have a backup of this file first and to not edit until recommended by VMware support.
.vmx file is a plain-text file that functions as the structural definition of the VM. The
.vmx file can be copied from the datastore and opened using a program that supports creation and saving of files using UTF-8 encoding, such as WordPad. The following excerpt shows an example of a
.vmx file for a virtual machine named
.encoding = "UTF-8" config.version = "8" virtualHW.version = "10" nvram = "ExampleVM.nvram" pciBridge0.present = "TRUE" svga.present = "TRUE" pciBridge4.present = "TRUE" pciBridge4.virtualDev = "pcieRootPort" pciBridge4.functions = "8" pciBridge5.present = "TRUE" pciBridge5.virtualDev = "pcieRootPort" pciBridge5.functions = "8" pciBridge6.present = "TRUE" pciBridge6.virtualDev = "pcieRootPort" pciBridge6.functions = "8" pciBridge7.present = "TRUE" pciBridge7.virtualDev = "pcieRootPort" pciBridge7.functions = "8" vmci0.present = "TRUE" hpet0.present = "TRUE" displayName = "SampleVM" extendedConfigFile = "ExampleVM.vmxf" virtualHW.productCompatibility = "hosted" memSize = "384" sched.cpu.units = "mhz" powerType.powerOff = "soft" powerType.suspend = "hard" powerType.reset = "soft" scsi0.virtualDev = "lsilogic" scsi0.present = "TRUE" ide1:0.deviceType = "cdrom-image" ide1:0.fileName = "/vmfs/volumes/5099c3c8-d8fe7ee8-2961-005056903273/win2k3srvsp2.iso" ide1:0.present = "TRUE" floppy0.startConnected = "FALSE" floppy0.clientDevice = "TRUE" floppy0.fileName = "vmware-null-remote-floppy" ethernet0.virtualDev = "e1000" ethernet0.networkName = "Production" ethernet0.addressType = "vpx" ethernet0.generatedAddress = "00:50:56:bc:c0:47" ethernet0.present = "TRUE" scsi0:0.deviceType = "scsi-hardDisk" scsi0:0.fileName = "ExampleVM.vmdk" scsi0:0.present = "TRUE" guestOS = "winnetenterprise" toolScripts.afterPowerOn = "TRUE" toolScripts.afterResume = "TRUE" toolScripts.beforeSuspend = "TRUE" toolScripts.beforePowerOff = "TRUE" uuid.bios = "42 3c 4c d6 12 1e 5e c2-a4 a3 b6 89 95 9f 7a 75" vc.uuid = "50 3c 6f a7 75 fb 68 7c-d1 42 df f7 f8 9b f5 f2" chipset.onlineStandby = "FALSE" sched.cpu.min = "0" sched.cpu.shares = "normal" sched.mem.min = "0" sched.mem.minSize = "0" sched.mem.shares = "normal" sched.swap.derivedName = "/vmfs/volumes/5099c3c8-d8fe7ee8-2961-005056903273/ExampleVM/ExampleVM-7f1e3e76.vswp" uuid.location = "56 4d 9b 08 ee d9 6c e2-ab 67 3a dc 63 16 cb fe" replay.supported = "FALSE" replay.filename = "" scsi0:0.redo = "" pciBridge0.pciSlotNumber = "17" pciBridge4.pciSlotNumber = "21" pciBridge5.pciSlotNumber = "22" pciBridge6.pciSlotNumber = "23" pciBridge7.pciSlotNumber = "24" scsi0.pciSlotNumber = "16" ethernet0.pciSlotNumber = "32" vmci0.pciSlotNumber = "33" vmci0.id = "-1784710539" hostCPUID.0 = "0000000b756e65476c65746e49656e69" hostCPUID.1 = "000106a50002080080b822291fabfbff" hostCPUID.80000001 = "00000000000000000000000128100800" guestCPUID.0 = "0000000b756e65476c65746e49656e69" guestCPUID.1 = "000106a500010800809822010fabbbff" guestCPUID.80000001 = "00000000000000000000000128100800" userCPUID.0 = "0000000b756e65476c65746e49656e69" userCPUID.1 = "000106a500020800809822010fabbbff" userCPUID.80000001 = "00000000000000000000000128100800" evcCompatibilityMode = "FALSE" vmotion.checkpointFBSize = "4194304" cleanShutdown = "TRUE" softPowerOff = "FALSE" ide1:0.startConnected = "TRUE" toolsInstallManager.lastInstallError = "0" tools.syncTime = "FALSE" tools.remindInstall = "FALSE" toolsInstallManager.updateCounter = "1" unity.wasCapable = "FALSE"
Reading through this file gives us important information regarding the configuration of the virtual machine. Here are a few examples:
The VM's configured guest operating system can be derived from the
Based upon the
memsizeline, it is known that the VM was configured for 384 MB of memory.
The virtual machine only has one network adapter configured for the VM network port group based on the
The virtual machine's vNIC has a MAC address of
00:50:56:bc:c0:47, specified by the
.vmx file is extremely important to the virtual machine. However, keep in mind that it only structurally defines the VM's virtual hardware composition. It does not hold any actual data from the guest OS running within the VM. The virtual machine's data is stored in its virtual disk file. Here is an overview of the configuration and BIOS files:
.nvram: This is generally a fairly small file that contains the BIOS settings that the VM uses upon boot. This is similar to how a physical server that has a BIOS chip allows hardware configuration options. The virtual BIOS settings, contained in the
.nvramfile, can be accessed by pressing F2 when the virtual machine is powered on.
.vswp file is created when the virtual machine is powered on. The size of the
.vswp file is equal to that of a configured memory, unless there is a reservation. When a memory reservation is configured for a VM, then the
.vswp file size would equal the configured memory size minus the memory reservation. This file is used as a last resort when the hypervisor is reclaiming physical memory from its virtual machines, due to contention. Memory reclamation techniques are discussed in Chapter 6, Virtual Machine Performance and Resource Allocation.
Looking at the previous table, you may have noticed the
vmx-<vmname>.vswp file. This file is for the overhead memory created for a VM, a new feature in vSphere 5.x. Historically, this memory overhead was not swappable. Though there was a memory reservation to back this, the entire address space did not actually have to reside in memory. This file helps to reduce the reservation requirements for virtual machines.
.vmdk: Virtual disk descriptor, which holds information such as the size and disk geometry of the virtual disk, information that makes the VM believe it has a real hard disk and not files on a datastore. Such information includes the virtual disk's adapter type, drive sectors, heads, and cylinders. This descriptor file also contains a pointer to the larger data file for the virtual disk or the
-flat.vmdkfile. An example of this information is demonstrated in the following screenshot:
-flat.vmdk: This file actually contains the virtual disk's data. This is created by default when a virtual hard drive is added to a virtual machine that is not using the Raw Device Mapping (RDM) option. When created as a thick provisioned disk, it will be sized approximately to what was specified in the creation wizard. The different disk provisioning types will be discussed in Chapter 2, Creating a Virtual Machine Using the Wizard.
-rdm.vmdk: This is the mapping file for the Raw Device Mapping (RDM) option, managing the RDM device's mapping data. The virtual machine isn't aware of this since the mapping file is presented to the ESXi host as a traditional disk file and available for normal filesystem operations. The storage virtualization layer presents the mapped device as a virtual SCSI device to the VM. An
–rdm.vmdkfile exists for each RDM configured for the virtual machine. RDMs will be discussed in more detail in Chapter 2, Creating a Virtual Machine Using the Wizard and Chapter 10, Virtual Machine Design.
-delta.vmdk: These files are only used when creating snapshots. When a snapshot is created, the original
–flat.vmdkfile is no longer written to; it becomes read only. All changes that are written to the virtual disk are now being written to the
–delta.vmdkfiles instead. Due to the fact that these
–delta.vmdkfiles are bitmaps of changes made to a virtual disk, the
–delta.vmdkfile cannot exceed the size of the original
–delta.vmdkfile is created for each snapshot that is generated. These
–delta.vmdkfiles are updated in 16 MB increments as changes are written to the virtual disk.
.vmsd: This file is a snapshot descriptor that contains information regarding which files are used by each snapshot, description, display name, and any associated UIDs. There is only one
.vmsdfile per virtual machine, regardless of how many snapshots the virtual machine has. This file is updated each time a new snapshot is created or a snapshot is deleted.
.vmsn: This file stores the virtual machine's state at the time the snapshot was taken. The size of this file varies depending on whether the option to include the VM's memory state was selected during snapshot creation. A separate
.vmsnfile will be created for each snapshot and will automatically be removed when the snapshot is deleted.
.vmss: This file is used when a virtual machine is suspended so as to preserve the VM's memory contents; it is only present when the VM is suspended. When the virtual machine is resumed from the suspended state, it can start again right from where it left off. The contents of this file are written back to the ESXi host's physical memory when the virtual machine is brought out of a suspended state; however, the file will not be automatically deleted until the VM is powered off. This file will be approximately the same size as the configured memory for the virtual machine, unless memory contention is present.
.log: Log files are created in order to log information regarding the virtual machine, typically used during troubleshooting efforts. The current log file is always named
vmware.log, and by default up to six older log files will be retained. These older log files will have a number appended at the end of their names, which will be updated with each file (
A virtual machine's files can either reside on a VMFS or a NFS datastore. The vSphere Client or the vSphere Web Client can be used to browse the datastore and display a virtual machine's files.
First select the virtual machine in the inventory.
On the VM's Summary tab, there is a Resources pane that lists all the datastores being used by the selected VM.
Right-click on a datastore and select Browse Datastore... from the available options.
This is demonstrated in the following screenshot:
This process opens the Datastore Browser, which is a handy tool to quickly display the contents of any datastore. The virtual machine's files can be displayed by selecting the VM's directory, as shown in the following screenshot:
The Datastore Brower shows that the virtual disk consists of only a single file, the
.vmdk file. This is not indicative of reality; there are actually at least two files that make up the virtual disk, the
This is shown in the following screenshot:
Notice that the
–flat.vmdk file is displayed in this view. This is the only view in the vSphere Client where the
–flat.vmdk file is shown. All other views show only the
If the vSphere Web Client is installed, then the virtual machine files may also be viewed using it. This view is the vSphere Web Client equivalent to the vSphere Client's Datastore Browser. Once the vSphere Web Client is launched:
Browse to the Datastore and Datastore Cluster view.
Once in this view, select the datastore that the virtual machine resides on in the inventory pane.
From there, go to the Manage tab and select the Files button.
The datastore directories will be listed on the left-hand side. Select the virtual machine; the results will look similar to what is displayed in the following screenshot. Note that the
–flat.vmdkfile is not shown:
Alternatively, the files can be displayed via a command line. Ensure SSH is enabled on the ESXi host that the virtual machine is located on and use an SSH client, such as PuTTy, to establish a connection. For steps on how to enable SSH, check http://vmware.com/kb/1017910. Navigate to the virtual machine's directory and use the
ls –l command to view the files.
VMware Tools is a utility suite that enhances the performance of a virtual machine's guest OS. If VMware Tools is not installed in the guest operating system, the guest will be lacking in some important functionality. The VMware Tools utility improves virtual machine management by replacing the generic OS drivers with VMware drivers optimized for virtual hardware. The following components are included after the installation of VMware Tools:
The VMware Tools service
VMware Tools device drivers
The VMware user process
The VMware Tools service passes information between guest operating systems and the ESXi host; service starts when the guest OS boots. This runs as a
vmtoolsd.exe program in Windows,
vmware-tools-daemon in Mac OS X, and
vmtoolsd in Solaris, FreeBSD, and Linux guest operating systems.
This service can run scripts that help automate repetitive guest operating system operations. Synchronization of the guest operating system time with the time on the ESXi host (with the exception of Mac OS X) can be configured with VMware Tools, though this is not necessarily recommended. Another benefit is the ability to move the mouse cursor freely between a Windows guest operating system in the VM and the vSphere Client (otherwise, Ctrl + Alt must be pressed in order to release the cursor from the VM console). Windows operating systems have the ability to quiesce snapshots used by certain backup operations provided by the service. VMware Tools also provides the process that sends heartbeats to VMware products to indicate that the guest operating system is running.
VMware Tools device drivers refine mouse operations and improve performance of networking, sound, and graphics. The guest OS will determine which drivers are installed with VMware Tools. The following device drivers can be included with VMware Tools:
The VMware user process starts when a user logs in to a Windows guest OS or starts a desktop environment session in Linux. The process' program file is called
vmtoolsd.exe on Windows guest OSes and
vmusr for FreeBSD, Solaris, and Linux operating systems. This allows for copy-and-paste interaction between the guest operating system and the vSphere Client, matching the screen display resolution of the guest with that of the vSphere Client.
VIX support is provided for using the VMware VIX API for guest operating system-bound API calls. The VIX API allows for the automation of virtual machine operations on the ESXi platform.
A vSphere administrator needs to understand virtual machine concepts before creating virtual machines. A virtual machine is a set of virtual hardware presented to a guest operating system whose characteristics are determined by a set of files. There are multiple VMware file types that are associated with and make up a virtual machine and are located in the VM's directory on a datastore. These files include the
.log files. Each virtual machine is equipped with virtual hardware and devices, such as one or more virtual CPUs, memory, video cards, IDE devices, SCSI devices, DVD/CD-ROM, parallel and serial ports, and network adapters, that provide the same functionality as physical hardware. Once the administrator understands that the virtual hardware is available, the next step is to learn how it can be configured. VMware Tools is a utility suite that enhances the performance of a virtual machine's guest OS. VMware Tools should be installed in every virtual machine to ensure the virtual machines aren't lacking in any functionality.
The next chapter will discuss how to create a virtual machine using the wizard and other associated configuration options.