vSphere Essentials: Virtual Machines
The VMware component that allocates CPU, Memory, and Input/Output is called Hypervisor. The installation of ESXi software right on top of the physical server (Dell Server in our case) is called bare-metal hypervisor architecture. So, an x86-based system running the virtualization layer directly is the bare metal hypervisor. This bare metal hypervisor option is common in real-life environments. There is another option called the Hosted Virtualization (also referred to as Host-based virtualization) that is also available.
After taking the VMware class where you performed various labs on high-end servers, you might want to practice the same labs at home. You might not have those high-end servers at home, but you still have your home desktop or laptop with your Windows OS or Linux OS installed. You can purchase VMware Workstation, reasonably priced, from VMware and install that on a Windows-based machine; VMware Fusion is available for MAC users. Then, on top of that VMware workstation or VMware Fusion, you can create VMs with the Windows 2008/Exchange setup we discussed before. Unlike the previous example, this is done on top of an OS, such as Windows, Linux, or Mac OSX/Lion. Since this is hosted on one of these OSs, this is called a hosted solution. This might be perfect for your lab environment but not really recommended for a real production environment since you are then running these VMs (VM with Exchange or your databases) on VMware workstation that is itself running on top of your home version of Windows 7. I hope that screams NO to you as much as it does to me.
Let’s get back to our bare metal solution. I still have a legacy OS like Microsoft’s Windows NT, for example, that I need to maintain in my production environment. Now, imagine that your existing Windows NT system is dead and you need to get that up and running fast. You don’t have those legacy servers anymore, and the high-end new servers and their components might not be recognized by an older OS like Windows NT. This is a perfect candidate for virtualization because these I/O calls are going through the Hypervisor. So, another advantage of doing virtualization with VMware’s vSphere is that you have support for legacy OSs on your new hardware (ESXi Host).
What Is a Virtual Machine?
To the Server Administrator, the virtual machine is just another machine/server. They just remote desktop protocol (RDP) to this system as they have done before. But what is a VM to a vSphere Administrator or to the Hypervisor? To us, the VM is nothing but a “bunch of files.” There are many files with various extensions that make up the VM. We could directly manipulate some of the files to affect the VM even though it might be reserved for advanced vSphere administrators. Many times the GUI gives you the control you need so that you don’t have to manipulate the files directly even though you can.
Some Files That Make Up a Virtual Machine
So what’s in these files? Well, everything. For example, we have a .vmx file that contains the VM configuration. The name of the file will be whatever you called the VM with the .vmx extension. .vmx is the main file for the VM. In the GUI, when you use the wizard to create the VM, all the answers to the wizard questions are in this file. This includes information on the Guest Operating System, Networking, and other things such as disk sizes. So, .vmx – a simple text file – is an important file that is stored in the same place where your VMs are stored.
Another important file is the .vmdk file extension. Again, the name of the file is the name of the VM followed by the .vmdk extension. You can see this using your vSphere Client, selecting your VM, and looking at the properties/settings of the VM. Once you see the Datastore, you can right-click and select Browse Datastore from the menu. However, if you use the Storage Views tab (select the VM and click on the Storage Views tab), you will see all the files related to the VM:
- The .vmdk file is not the real disk content; it is just the virtual disk characteristics. The –flat.vmdk file is the one that contains the virtual disk’s data.
- The .log files are very helpful when working with VMware support folks for troubleshooting.
- The .nvram is the actual VM BIOS.
- The .vmsd is for VM’s snapshots.
- The .vmsn is the state of the RAM of the virtual machine if you chose to take the snapshot of the memory.
- The .vmtx is the one you will see if you are using Templates. This is good if you deploy multiple VMs and you don’t wish to answer individual questions while going through installation wizards and various other prompts.
VM uses virtual hardware. The guest OS you use in the VM has no idea that the hardware is virtual (remember, this will be defined in the .vmx file or through some GUI wizard). There have been many iterations of what hardware can be configured for the VM called the hardware version. Different hardware versions are available in different versions of products from VMware. Hardware version is going to be one of those questions you get to answer when you are going through the wizard to create the VM. So what hardware version should you pick?
Well, it is true that the newer hardware versions are available on the newest versions of the ESX product line. For example, for EXSi 5.1, hardware version 9 is the newest version (as of this writing). If you have a mixed environment of ESXi 5.1 and some older versions, then you should not pick hardware version 9 when you create a VM. Here is a list of hardware versions that we have been through.
- ESX 2.x gave us Hardware version 3
- ESX 3.x gave us Hardware version 4
- ESX/ESXi 4.x gave us Hardware version 7
- ESXi 5.0 gave us Hardware version 8
- ESXi 5.1 gave us Hardware version 9
The newest Hardware versions give us more capabilities and hardware support. For example, Hardware version 7 gave us the ability to create VMs with 255 GB of RAM, and in Hardware versions 8 and 9, we can create VMs with 1 TB of RAM. In Hardware version 7, you could have a maximum number of 8-way Virtual SMP. Hardware version 8 gave us maximum of 32 vCPU support, and Hardware version 9 has now doubled that to 64 vCPUs (all with proper licensing; contact your VMware rep for licensing information).
If I built a brand new VMware vSphere environment with the ESXi 5.1 version, then picking Hardware version 9 makes sense for me since all I have is ESXi 5.1. But if I have an existing environment with a previous version of ESX/ESXi, then I’ll look at what Hardware versions are supported if I intend to move these VMs between hosts with different versions (ESX has been discontinued starting with version 5 of the product line where we only have ESXi).
Reproduced from Global Knowledge White Paper: VMware vSphere Essentials
VMware vSphere Essentials Series