Welcome back to vSphere 8 in the real world. Now we're going to discuss virtual machines.
So what's a VM? So a VM is basically a operating system and applications and or applications,
right, using software instead of hardware. So we have physical hardware and we install ESXi on
there, for example, within a vSphere environment. And then we create this container that we call a
virtual machine. And the virtual machine is going to virtualize things like hard drives and access
to memory and processor access and network adapters and all those, a bunch of different
types of things, USB controllers and disk controllers and all this stuff. And that
software is virtualizing to the software that we're running inside that container. For example,
we have ESXi installed on the hardware and we may be running Linux inside that container. We might
be running Windows inside that container. But it's just software that's virtualizing the hardware.
So that way we can have multiple operating systems running on one physical piece of hardware, but they
don't know about each other. They're all being containerized, being separated from each other
by the hypervisor, which is in this case ESXi, as we were just talking about.
All the VMs function separately. They're not aware of each other. If one of them wants to
talk to the other one, they're going to do it the same way they would do it if there are physical
boxes. They're going to put packets onto their virtual network adapters, which they think are
real network adapters, and send it over the wire. One thing that's interesting about virtualization
as it's gotten more mature is that vendors like Microsoft and Linux, everybody, have started
writing the software to be more aware of virtualization. The VMs don't all of a sudden
behave completely differently, but they're more aware of the virtualization to make them run
more efficiently in that hypervisor environment. They have drivers that run more efficiently
inside a virtualized environment and things like that. The operating system isn't really
fully aware, but it does have some tweaks to make it more efficient. It provides applications
resources. Multiple users can be running different platforms on one physical box running,
for example, again, ESXi. I might have several Windows boxes. I might have Windows 2016 and
Windows 2024, and I might have some different versions of Linux. I might be running Alma,
Linux, and Red Hat Linux, and maybe Ubuntu. I can run a bunch of different things on one
piece of hardware. They can all be running different applications. I might have Apache
running. I might have Microsoft SQL Server running. I might have something from Sage
software running. All these different things are all running on this one piece of hardware.
So, I'm utilizing that hardware much more fully than if I use it to just install one service,
like Active Directory and Directory Services or something like that.
So, before virtual machines, I had a piece of hardware. I installed Windows on it or Linux on
it and my application. Maybe I made it a domain controller, so I was running, you know, AD,
or maybe I was running Linux on there and it's running Apache or something like that.
But it was really kind of dedicated. That OS controlled all the hardware on that box
and is available to the application running on that box.
Now, with virtualization, I'm able to take that same box and maybe that same server, that box,
has, you know, way more CPU than my applications need and way more RAM than my applications need.
I've got, you know, four different 25-gig network interfaces in there,
way more than my applications need. So, what I can do is install multiple operating systems
inside of virtual machines on that hardware, put different operating systems on there,
put different applications on there. They can be patched differently. We can create policies
and we patch them the same. That would be efficient. But they can be completely different,
running different applications and all on that same hardware, right? Those are virtual machines,
those little virtual boxes. So, files. Virtual machines are just files on the hard drive. So,
I might have on a Windows box a file that is just an EXE file. But that file, when I click on it,
it runs SQL Server and it knows what it's supposed to do. SQL Server knows all these jobs it's
supposed to run. On a hypervisor, I might have files. And when the operating system, for example,
ESXi, loads those files, it knows what to do with them. So, it says, okay, I'm going to load this,
which is a VMX file. And that VMX file says, here's where your virtual hard disk is and here's
where your RAM is and how much RAM you have. Oh, by the way, create a swap file of a certain size.
Here's the disk controller that your hard drives are connected to. And then here's the size of your
hard drives. Actually, it'll say, here's where your VMDK files are. And that will all define
the hard drives, things like that, right? So, really, your virtual machines are just
files on a hard disk. And then the hypervisor knows how to read those and interpret those and
make them be virtual machines, run the workloads that they're expecting from that virtual machine,
right? You can configure things through vSphere. You can use the ESX CLI, which is a command line.
There is an SDK you can use for configuring things. There's also, obviously, just your
traditional web console, your DCUI console, like your video card console on there. Files are
stored. They're stored on hard drives. And if you alter those files, you're like, oh, I'm going to
tweak this file over here, you might find your VM isn't running anymore. It might seem like, oh,
it's just going to do this one thing and you know what it's going to do. And then all of a sudden,
that VM isn't running anymore. So, just be really careful if you're not really, really familiar with
these files before you start doing things like editing those files by hand. So, what kind of
files do we have? So, the VMX file, as I said, is a file that actually defines a virtual machine.
It can be a really small file. It can be, like, you know, measured in K. You can read it in Notepad.
Don't want to edit or change it, but you can read it. And it defines that virtual machine.
A VMXS file is just actually a file for additional configuration information.
There is a VMSS, which is a suspend file. So, if you were to suspend a virtual machine,
it's going to write everything that's in RAM to that file, and all the CPU register information
gets written over there, too, right? And then you have a VMIM, which is basically a backup
file for your paging memory. VMDK, so the VMDK file, just .vmdk, it actually defines the virtual
disk and says where the data file is, a dash flat .vmdk. So, before the dash will be the name of
the virtual machine, dash flat .vmdk. And that is actually where the data is written for the
virtual disk, and the VMDK points to the flat file and defines it. You have your nonvol around file
that has all your BIOS information in there and things like that. Your .vfwp is your swap file.
So, if the host is running low on physical RAM, it can start swapping things out from physical RAM
that belongs to the virtual machine into that file, and the VM thinks its information is still in RAM.
So, it goes, oh, give me that page of RAM. The ESXi host will say, oh, that page of RAM I wrote
to the swap file, read it from the swap file, put it back in RAM, and give it to the VM. Obviously,
that's a very slow process. So, if you're swapping, your performance is being very negatively impacted.
You have your snapshot files. You can snapshot VMs. So, basically, when you go to create a snapshot,
it creates this file to help monitor and track what's being changed from the VMDK file.
You have your log files. Old log files will have a number or something,
.log, so you know those are the older ones. The higher the number, the older it is. Actually,
sorry, the higher the number, the more recent it is, the lower the number, the older it might be.
But it's in a circular log, so what you want to do is check the timestamps.
And a VMTX is basically the exact same thing as a VMX file, but it's designated as a template,
so it can't be turned on. So, really, what you can do is if you have a virtual machine that's
turned off, when you right-click on it and you say convert to a template, all it has to do is
rename that file from VMX to VMTX, and now you just have a template. So, that's really all there
is to that. So, a guest OS is an operating system that is different than the operating system
running on the hardware. So, on the hardware, I have my hypervisor. It might be Hyper-V,
in a vSphere environment, it's going to be ESXi. Inside my guest OS, it will maybe be
Windows or Linux or some other operating system. There are some other ones out there. Now,
it's possible to virtualize in a VM ESXi. So, you might actually have ESXi running on top of ESXi.
You might have Hyper-V running on top of ESXi. That's called nesting, hypervisor nesting. So,
you can do that as well. But basically, guest OS is the OS running in the VM versus the OS
that's running on the hardware.