Section 1.3. VMware Terms and Concepts
1.3. VMware Terms and ConceptsConceptualizing a virtual server or virtual environment is for some the most difficult step toward moving to a virtualized environment. Virtualization has actually been around for decades in the mainframe space, but most Windows administrators have not had the opportunity or inclination to dabble in it. In the x86 world, where many IT professionals currently live and breathe, a virtual machine is a relatively new concept. As with any newer technology, there are some fundamental terms and concepts that should be defined, and we'll go over those in this chapter. Understanding each of these terms and concepts will make the rest of the book that much more accessible, so it is essential to grasp what is presented in this opening chapter. Terms beget more terms, which beget even more terms, so although there is some rationale to the order in which the vocabulary and concepts are presented here, their order often hinges more or less on how they are connected within the mind of the writerso be warned. 1.3.1.1.3.1.1. HostA host is the physical computer on which you load your VMware product. ESX has an approved systems compatibility document that can be found at http://www.vmware.com/pdf/esx_systems_guide.pdf. Prior to purchasing ESX Server or any hardware, read this document. You should refer to this guide to ensure compliance. VMware is supported on the major platforms. Nothing is more frustrating than tying to troubleshoot a hardware issue only to find out that the hardware you've purchased is not supported. Avoid this by reading the compatibility guide before acquiring any hardware. The number of virtual machines you want to run simultaneously, as well as the types of loads these virtual machines will place on your host, will determine the physical requirements of your host. The host is what the ESX product is installed on. When talking with virtual-newbies about virtualization, a common mistake is to equate a virtual machine with a dual-boot systemwhich it is definitely not. Our second term is thus virtual machine. 1.3.1.2. Virtual Machine (VM)Virtual machines are also referred to as virtual servers (not to be mistaken for the Microsoft product of the same name), guests, or the guest OS in other documentation you might read. Throughout this book, we'll use these terms interchangeably to mean the same thing. (In a Webinar for Microsoft's Virtual Server 2005 product, the tech giving the Webinar even referred to his virtual servers as VMs. I thought that was telling.) We'll discuss the long list of guest OSes supported by VMware later in Chapter 3. For now, let's do a quick recap. The host is the physical machine on which you load your VMware platform product (ESX, GSX, or Workstation) and run your VMs or guests. So what makes up a VM? Well, what makes up the core of any computer, really? Most computers must have at least a single processor, some physical memory, and a hard drive. And if you want it on a network, it needs a network interface card (NIC). These are four basic, or core, components for all VMs as well. The processor(s) of your physical host are shared between your host and your VMs. We will discuss how this works in Chapter 3. There are different default levels of memory for the various supported guest operating systems when you create the configuration file (Chapter 3 as well) for your VMs. These levels can be changed when the VM is built or powered off. Memory is very important in the VMware world, and if you over-spec your host at all, do it with memory. If the VM is going to play on your network, it will need at least one NIC. Virtual networking will be touched on in Chapter 2, while all of Chapter 5 is dedicated to networking functionality and possible solutions. But the heart and soul of a VM is its disk file, so I will go over it briefly here and then dive deeper into it in, you guessed it, Chapter 3. In VMware ESX Server, the hard drives are files similar in nature to any other file. They can be copied and moved. These hard drive files in ESX have an extension of .vmdk. In earlier versions of ESX Server, the extension was .dsk. It is in these .vmdk files that the operating system of your VM is kept. Regardless of which operating system you install, all operating system files are kept in the .vmdk file that is created when you build a VM. All data and applications in your VM are also kept in the .vmdk files. The idea of your operating system and applications being placed in .vmdk files brings us to our next term: encapsulation. 1.3.1.3. EncapsulationAll OS and data files reside within the .vmdk file(s); thus, the server is encapsulated within this one, or potentially more, file(s). (You can have more than one virtual hard drive.) This is an important concept to grasp. Throughout this book, I will be giving examples of how flexible a virtual machine or virtual environment is. This is true in part because of encapsulation. In the GUI world (either Windows or Linux), it is easy to right-click a file, copy, and paste it somewhere else. Many files are portable, and like anything else that is portable, they can be moved around easily. If VMs are encapsulated within .vmdk files, your VMs are portable; thus portability is our next term. 1.3.1.4. PortabilityPortability is the ability to move virtual machines either physically or logically to another location with little effort or reconfiguration. Portability allows you to run your virtual machines on any supported physical host. The following is an example of portability. During a client engagement with a large insurance company in upstate New York, some of the servers that needed to be virtualized and consolidated were located in Louisiana. The server had been physically relocated years earlier, but the asset inventory system did not show thisa small detail overlooked by the company's IT department. This normally would be a serious issue that would incur greater expense and lengthy project delays. But the consultant was able to virtualize (through a P-to-V processour next termand a decent WAN connection) the three servers remotely, and FTP the now virtual machines over the intranetall within ten hours. Now that's portable. Moving servers from the deep South to the far North in less than a day is the epitome of portability. Portability stems from encapsulation, and these two aspects of a virtual environment lend greatly to the power and flexibility of VMware. It is important that you understand these two terms, as they will be a part of the foundation for planning, designing, and implementing your virtual infrastructure. A simpler example is to imagine that you have a Windows 2003 Enterprise Server virtual machine. You need another, for creating a cluster. Through the ESX Management Console you select the .vmdk and choose copy. In a couple of minutes, depending on the size of the .dsk, you have a new server. Thus, you have provisioned a server in minutes instead of days or weeks in the physical world. Totally sweet! We'll go over this in detail in Chapter 3. As I mentioned earlier, our next term is P to V, or physical to virtual. 1.3.1.5. P to VP to V is a migration process through which a physical server is turned into a virtual server; thus, physical to virtual, or P to V. There are a number of ways to accomplish this migration. VMware has its own tool called P2V Assistant, which is decent, although good for only Windows servers. However, at the time of this writing, you may need to reapply service packs and hotfixes, so if you have physical servers that have gone through a certification process, your virtual servers may need to be recertified, which can add time and cost to your virtualization project. There are other methods as well, three of which I will talk about in greater detail in Chapter 6, "Physical-to-Virtual Migrations. "Additional third-party P-to-V tools are available. All virtualization projects will have to include a method to migrate physical servers to virtual ones. I would highly recommend understanding the concepts in Chapter 6 thoroughly so that you may better choose the tool that best fits your needs and skill set. You will quickly get discouraged if you cannot successfully migrate your servers into a virtual environment. Retiring your legacy hardware while your newly virtualized machines run in parallel, are completely isolated from one another, and exist in an idealized, up-to-date hardware environment will increase your legacy application performance, reduce hardware purchases and server sprawl, and ignite your virtual evolution within your environment. Two concepts I mentioned already in this section, isolation and idealized hardware, need further defining. 1.3.1.6. IsolationVirtual machines run in a completely isolated environment from one another; therefore, if one virtual machine crashes, it will not bring down the rest of the virtual machines on the same physical host. Each virtual machine is its own process, wholly independent, running in its own memory space. This provides increased stability, eases administration by allowing work to be done on one virtual machine without that work affecting other virtual machines on the same physical host, and sharply reduces the total cost of ownership of that server. Note: If your physical host goes down, then all of your virtual machines will go down. It is important to purchase quality hardware for any production physical host. Some tweaking can be done on the host operating system, all of which needs to be thoroughly documented and tested in your test lab. Performance tweaking will be discussed in Chapter 2. 1.3.1.7. Idealized HardwareHistorically, many Blue Screens of Death (BSOD) in the Windows world were caused from the operating system and the hardware not playing nicely with each other. Driver and firmware incompatibilities could wreak havoc on your system. VMware gets rid of this issue by providing an idealized hardware environment on which your guest operating systems can run. This environment is exactly the same regardless of the actual, physical platform upon which you run your virtual machines. So if you move your virtual machines from one ESX Server that is running on an HP physical host to another ESX Server running on a Dell, the virtual machine will never know. There are hardware specifications to run ESX Server, which we'll get into in the next chapter. However, your virtual machines see the same idealized hardware no matter what the platform. This concept of idealized hardware in theory reduces the number of system crashes, which improves your uptime numbers, your end-users' experiences, and the overall availability of your servers and services. So what provides the idealized hardware you might ask? The answer to that question (and, surprisingly enough, the next term we'll be covering) is the virtualization layer. 1.3.1.8. Virtualization LayerThe virtualization layer provides the idealized hardware resources that your virtual machines utilize. Also known as the VMkernel, the virtualization layer, runs directly on the physical hardware of your ESX Server. The virtualization layer is what ESX Server provides to your virtual machines in the way of resources. Through the virtualization layer, your virtual machines are given virtual CPUs, hard drives, RAM, and NICs, as well as other resources that we will discuss in Chapter 3. Figure 1.1 shows ESX Server's physical resources, which the virtualization layer translates into virtual resources that can be allocated to virtual machines with different operating systems. Figure 1-1. ESX Physical Host and the Virtualization Layer Figure 1.1 shows Windows, Linux, and Novell virtual machines all running on the same ESX Server and accessing the idealized hardware components presented to them by ESX through the Virtualization Layer. It is only the virtual resources that the guest OSes access, and since these are ideal for the individual OSes, hardware issues become nearly nonexistent. Although Figure 1.1 depicts only three virtual machines accessing resources, the number of virtual machines on each physical host can easily reach into the twenties or thirties or more, depending on the size and specification of your physical host and the services the virtual machines provide (database, e-mail, and so on). Nonetheless, this is a tremendous consolidation ratio. Two components of the virtualization layer (and your next two terms) deal with networking. They are VMnet and VMnic. 1.3.1.9. VMnetVMnet is a software switch or virtual switch that provides high-speed network traffic routing between virtual machines on the same ESX Server or host. 1.3.1.10. VMnicVMnic is what ESX server calls a physical NIC that is allocated for virtual machines. A VMnic is generally bound to a virtual switch to route network traffic to your production network, the Internet, or other virtual machines. The difference between a VMnet and VMnic is that a VMnet is purely virtual and not bound to any physical NIC, while a VMnic is a physical NIC that can be bound to a virtual switch. Let's define a virtual switch. When you first install ESX Server, you will be prompted to create a virtual switch. 1.3.1.11. Virtual SwitchA virtual switch is a software switch that you create in ESX. It has 32 logical ports that you plug your virtual machines into so that they can talk (send and receive network traffic) to each other, communicate with your production network, and/or the Internet. Virtual switches provide tremendous flexibility, and we will discuss them in greater detail in Chapter 5. Once your ESX Server is up and running, many of the changes to it, such as setting up a virtual switch, will be done from the management user interface (MUI). The MUI is the management console of your ESX Server. It is Web-based (running on Apache) and is set up by default when you install ESX. Over 90 percent of the common day-to-day tasks you will need to perform on your ESX server will be done through the MUI, and it is an interface with which you will become intimately familiar. ESX Server is Linux based, and some terms may be unfamiliar to Windows administrators. We will discuss the command-line interface and the file system of ESX in greater detail later in the book. If you are strictly a Windows person and beginning to work with ESX, you will feel the pain of elucidation that comes from working within a Linux-based environment. We will now discuss a couple of Linux/ESX terms you'll need to understand long before you begin to read those later chapters, especially if you're looking to get ESX up and running as quickly as possible. 1.3.1.12. VMFS Volumes and Physical ExtentsWhen you install ESX Server, you will create what are called VMFS volumes. It is in these VMFS volumes that all of your production virtual disks, the .vmdks, that your virtual machines comprise, will run. So all of your .vmdks will go into a VMFS volume. The VMFS volume itself can itself span multiple partitions. These partitions are called physical extents. Physical extents can be partitions of local disks, LUNs from your SAN, and partitions from an external RAID array. Think of VMFS volumes as made up of physical extents. Physical extents are the disk partitions that you assign to your ESX server from the local disks, RAID, and/or SAN. 1.3.1.13. Swap SpaceSwap space may be a term you are familiar with, or you may know it as virtual memory in Windows parlance. It is also called a paging file. Swap space is a chunk of hard drive space that you allocate to allow either your virtual machines or your ESX Server Service Console to use if they run low on RAM. If your virtual machines run low on the virtual RAM you configure for them, they can free up their RAM by writing its contents to the swap space. This process is known as swapping or paging. As was mentioned already in this chapter, if you are to over-spec your host, do it with memory, which will help reduce the amount of paging. Generally, excessive swapping or paging degrades the performance of your system, virtual or physical. Sizing the amount of RAM you allocate to your virtual machines and the ESX Service Console is important to prevent excessive paging. Memory costs have plummeted, so max out the memory of your host if possible. In Chapter 2, we will discuss the recommended amount of swap space for your ESX Server. 1.3.1.14. RootRoot is the almighty. Root is the all-powerful account that is allowed to do anything on ESX Server (or any Linux\Unix-based system for that matter). It is the local administrator in the Windows world. However, Root is not just an account. It is the start of the file system as well. Denoted with a /, root or / is the C:\, or its rough equivalent. If you ever want to get back to root from anywhere in the ESX file system, just type cd/ and you will be back at root. When you install ESX, you will be asked for a root password. Guard this well as root has the keys to the kingdom and can do, or undo, anything on your ESX Server. 1.3.1.15. Case SensitiveNot so much a term or hard-core concept, it is, however, important to know and fully understand that ESX Server is Linux-based and therefore its files, directory names, and commands are case sensitive. When you create a file called, for example, mydisk.vmdk, it is not the same file as Mydisk.vmdk. It is recommended you come up with a standard naming convention for files and directories and stick to it. You will be creating virtual disk files, configuration files, .iso image files, directories, and sub-directories. If you create and adhere to a naming convention, it will make searching the file system that much easier. I recommend picking up a Linux book and familiarizing yourself with it. It will help out tremendously. You needn't be a Linux guru or anything, although that, too, would help. But you should be able to navigate the file system from the command line, open and edit files, and have a general understanding of how ESX Server is set up from a file-system perspective. ESX Server has a terrific Web interface called the management user interface, or the MUI. However, knowing the file system on which both of these things reside will, of course, benefit you. 1.3.1.16. MUIMost changes you make to your ESX Server and your virtual machines will be done through the management user interface (MUI, pronounced moo-eey). The MUI is the Web interface to the service console and runs on Apache, the Web server native to Linux. The default install loads a Secure Sockets Layer (SSL) certificate, so all communications to the MUI are encrypted. 1.3.1.17. The Service ConsoleThe Service Console is where you will manage your ESX Server as well as your virtual machines. Ironically, it is similar in many ways to a virtual machine itself. The Service Console is a customized version of Linux 7.2 and is run by the VMkernel, which runs your virtual servers as well. The vmkernel also handles all the scheduling for the Service Console. The Service Console has been customized to run virtual machines, and many services have been turned off in order to better support the virtual machines. Because the primary role of the Service Console is to run virtual machines, resource-intensive workloads should not be placed on the Service Console because it may affect the performance of the virtual machines. You can access the Service Console as you can many other Linux distributions. If you're a Windows engineer or administrator, become familiar with Putty (which you can download for free off the Internet), a Windows-based SSH tool. From another Linux\Unix platform, you may, of course, use SSH directly. 1.3.2. Author's NoteSome of the screenshots, exclusively those used in Chapter 2, were taken from installing ESX on a GSX server. This is not a supported installation method and was used only to capture screenshots. All other screenshots, tests, scripts, and configuration information were taken from ESX installations on the platforms shown in Table 1.1.
Because an ever-increasing number of acronyms are used every daythe alphabet-soup issuethe writing style in this book will at times use the acronym and at times write out what the acronym stands for. An example of this is VM, or virtual machine. Another, as seen in the MUI paragraph, is MUI, or management user interface. This is an intentional shift from writing a term such as Management User Interface and then in parentheses writing the acronym and then from that point forward only using the acronym. We're simply trying to reinforce acronym definitions in the reader's mind while at the same time allow for the use of acronyms for efficiency, which is really why acronyms exist. This we hope emulates more how people speak. |
EAN: 2147483647
Pages: 173