VMware Vsphere Basics

6/22/2020 VMware vSphere Basics (Main.Internal Technical Docs.Official Lectures.VMware vSphere Basics.
WebHome) - XWiki
 (/bin/view/Main/)  / Internal Support Portal (/bin/view/Main/) 

/ Internal Technical Docs (/bin/view/Main/Internal%20Technical%20Docs/) 
/ [obsolete] Official Lectures (/bin/view/Main/Internal%20Technical%20Docs/Official%20Lectures/) 
/ VMware vSphere Basics
(/bin/view/Main/Internal%20Technical%20Docs/Official%20Lectures/VMware%20vSphere%20Basics/) 
VMware vSphere Basics

Last modified by Oleg Kulagin (/bin/view/XWiki/okulagin) on 2019/10/16 09:48
Updated to 2019
Intro
Definition of a hypervisor
Hypervisor types
ESX vs ESXi
ESXi installation
ESXi internals
vSphere clients
Storage management
SCSI command protocol
iSCSI
Fibre Channel
NFS
Storage devices
vCenter
vCenter internals
vSphere vs vCenter vs ESXi
vCenter/cluster features
Licensing
Authentication and ports
Tags
Managed Object Browser (MOB)
VM files
Changed Block Tracking
Snapshots
Virtual Machine compatibility levels
VMware Tools
VMFS
Raw Device Mapping (RDM)
Disk provisioning types
Dependent vs Independent disks
Networking
Permissions
Virtual SAN (new in vSphere 5.5)
Virtual Volumes (new in vSphere 6.0)
https://xwiki.support2.veeam.local/bin/view/Main/Internal Technical Docs/Official Lectures/VMware vSphere Basics/ 1/28
6/22/2020 VMware vSphere Basics (Main.Internal Technical Docs.Official Lectures.VMware vSphere Basics.WebHome) - XWiki
Encrypted VMs
Storage Profiles
New in vSphere 6.5
Intro
The training is called “basics”, however one could even go as far as saying that these 5.5-6 hours is the
VMware Certified Professional course, condensed. This training excludes the most basic stuff such as “how to
create a VM”, but on the other hand goes deeper into the topics that are very important to Veeam (and other
backup solutions), such as snapshots and CBT.
Definition of a hypervisor
Virtual machines run in some virtual environment, on virtual, or synthetic hardware. That hardware is
virtualized/emulated, but it has to appear from somewhere, and that is created by a hypervisor. A hypervisor
could be an operating system (like in our case, since ESXi is the subject of our discussion), some piece of
software, or rarely, hardware.
ESXi is the VMware’s platform for virtualization and it is an operating system. It is installed on a physical
server, and virtual machines will be able to run there (and not necessarily “realize” that they run virtualized).
You will very commonly see two terms, host and guest, in our documentation and in general on the internet.
Host refers to the hypervisor — in our case, typically a powerful physical server with 512 GB of RAM and 128
CPU cores. And the machines are referred to as guests.
Hypervisor types
It is generally considered that there are two types of hypervisors. Type 1, which ESXi belongs to, is called
native, or bare-metal, and it is installed directly on the hardware and as such has the best possible
performance without any additional layers in-between. Type 1 is designed for enterprise/business
virtualization where you want to consolidate the resources and run as many VMs as possible on a single
server.
Type 2 is desktop virtualization. Here you have your desktop/laptop computer and run some software, which
has to operate on your existing OS such as Windows, Linux or Mac OS. Well known examples include
VMware Workstation/Fusion, VirtualBox, Parallels Desktop. The additional layer of the OS causes less
performance but that’s OK since in this use case you don’t care too much about performance, but rather
about usability.
Type 2 does not concern us at all, Veeam doesn’t work with these hypervisors, but experience with them will
definitely help you.
Hyper-V is also of Type 1, even though its installation process may suggest otherwise. The procedure is as
follows: you add a Hyper-V role to an existing Windows Server machine, and it’s activated after a reboot.
What happens under the hood is that BCD configuration is changed to boot the hypervisor first, and only boot
the original Windows installation later. Due to this, there is direct hardware access for the hypervisor, and
good speed. Hyper-V is a completely separate training however and will be covered much later.
ESX vs ESXi
Historically there was first ESX, based on Linux. These days you will probably never find a host with ESX
running on it, however version 4.1 is supported for backup as of Veeam B&R 9.5. It is ancient however, the
latest version was released in 2010.
At some point, VMware decided to re-design the hypervisor, and the result is ESXi, which is running on its
own kernel, named vmkernel, and it is not Linux. The idea was to focus entirely on virtualization and remove
everything else that is not needed. ESX had Perl, and ESXi no longer has it. However, it comes with Python
for whatever reason. Linux service console is no longer present and all VM management is done remotely
with the vSphere (Web) Client.
As of 2017, the most common versions of ESXi are 5.5 and 6.0, they have about the same share. The most
recent one is 6.5, and only a small portion of users have upgraded, since it’s generally a good idea to wait for
some updates to be released first. 5.1 and 5.0 are rare these days, and are also no longer supported by
VMware (but still supported for backups by Veeam).
There are often cases where an issue happens on the VMware side (ESXi or vCenter), and that is often fixed
by the respective updates. You probably can’t force a customer to upgrade, but instead you should strongly
recommend to have the latest patch level of their ESXi and vCenter.
ESXi installation
The installation of ESXi is very quick and straightforward as with any other modern OS. You’ll need to obtain
an .iso image from their website (or find them here: \\amust.local\SPB\Distribs\VMware\
(file://amust.local/SPB/Distribs/VMware/) ) and boot from it from a CD/USB drive or possibly even the
network. The image itself is very small, only about 350 MiB in size.
During the installation, you’ll need to provide only the following:
The password for the root account.

Partition to install to.
TCP/IP settings.
Time zone.
Keyboard settings.
Once it is installed and rebooted, you’ll see a yellow screen known as Direct Console User Interface (DCUI).
You probably won’t have access to a real physical server to see this screen, but in our labs you can look at
the Console screen of a virtualized (nested) ESXi server to see the same screen (look for test-esxi hosts).
DCUI shows the host’s hardware configuration and IP/hostname on which it is accessible on on the splash
screen. DCUI allows you to change the settings configured during installation, look at the logs, enable ESXi
shell and/or SSH access. These two remote access options are initially disabled due to security
considerations. ESXi shell is rarely used, but SSH is a quite common to way to get to the command line of
ESXi.
DCUI also has an option to “Restart Management Agents”, and this gets us to the topic of ESXi internals.
ESXi internals
ESXi runs many different processes, and the most important ones are these ones:
hostd is the management service (daemon) that is responsible for performing all the actions one
requests from ESXi. For example, if a VM needs to be created, then hostd will do the necessary steps

to do so. If hostd stops responding, then you can no longer manage the host via the vSphere Client,
and vCenter will indicate that the host is no longer available.
vmkernel isn’t a process but the kernel itself, which is responsible for all low-level system operations,
in particular working with the hardware and its drivers. Should something go wrong with the hardware,
the host is likely to crash into a Purple Screen of Death (PSOD), not unlike the BSOD on Windows.
Always remember that Veeam cannot directly cause a PSOD; PSOD is always a bug in the ESXi
kernel, driver or a hardware issue, and one should install the latest patches to try to prevent the issue
from re-occurring.
Every running VM is a separate process called vmx. All of them run independently and don’t share any
memory. Should one vmx crash, no other VM will be affected.
There are many other processes such as dcui and authd, but they are less important for us.
If hostd crashes or hangs, the VMs will still continue running. Instead of rebooting the whole host (and having
to migrate or shut down your VMs), you can try to use the “Restart Management Agents” option which will
restart the system daemons and potentially bring the host back to normal. This is a very common advice
when something’s not right with a host (e.g. all backups from a specific host fail), but you should be careful
and take no responsibility for this, since there are known side effects (MPIO may stop working).
vSphere clients
You can open your installed ESXi in a browser, over HTTPS, and after you’ll have accepted the self-signed
certificate, you’ll see the welcome page. The same works for vCenter as well.
From there you can, depending on the version, download the vSphere Client and/or access the vSphere Web
Client. vSphere Clients essentially allow you to do 95% of the usual virtual environment administration such
as configuring networking, storage, VMs and so on. As of 2017 there are four different clients in total. No
matter the version, you’ll have to log in with a valid account, which for ESXi initially is only root, with the
password created during the installation.
vSphere Client, also known as the C# client, or Legacy client, is the oldest known client which can
log in to ESX, ESXi or vCenter. Starting from vSphere 5.5 it is considered legacy, and no new features
(such as VSAN configuration) are available there, but otherwise it’s perfectly usable for 95% cases,
and most people still prefer to use it. Starting from vSphere 6.5, it is no longer shipped and no longer
supported at all.
vSphere Web Client, which runs in a web browser, was intended to replace the standalone vSphere
Client. Before vSphere 5.5 it was optional, and from 5.5 is the official primary client. This client is less
responsive in terms of performance since it’s made in Flash/Flex. For these reasons, it’s not preferred
by many customers. It also tends to crash a lot. But in 6.5 it’s the default client.
ESXi HTML5 Client is shipped with the more recent 6.0 and 6.5 ESXi hosts and is a perfect
replacement for the legacy vSphere Client, it runs in a browser and uses no Flash. This is what you use
now for the initial configuration until you deploy vCenter.
vSphere HTML5 Web Client is the latest client which should replace the Flash Web Client in the
future, but currently it doesn’t have all the features and is in active development. It ships with vSphere
6.5 and can be installed on 6.0.
Virtual machines run on the hosts, and to be functional computers they need to have a number of
devices/resources. For example, without a CPU and RAM computer cannot exist. There are optional
components such as (virtual) disks and networking cards, but in a modern server they are always expected,

otherwise the server can’t store any data, or it will be isolated from other machines. Then there’s also system
devices such as a CPU timer on the motherboard, BIOS, a simple video card, PCI bus and so on. We’ll now
talk about storage, which is a very important topic.
Storage management
If you have, say, an Exchange server with a 3 TB database, then that disk with the database has to be stored
somewhere. Here virtual machines are just a number of files, and disks are also stored just as files, so you’ll
need 3 TB of space for that virtual disk file on some physical storage.
The simplest way is to connect a disk directly to the host’s motherboard and store the VM files there. This is
called locally attached storage. It can also be not a single disk, but a RAID array on a RAID controller, but
that is still connected to a single host. The disadvantage is that no other ESXi host in your environment will
have access to that disk/RAID. This is inconvenient in terms of availability, since for example if your host
crashes, then to power on that VM you’ll have to evacuate and put that data on another host, which may take
a considerable amount of time. Furthermore, this cannot be automated. Another issue is of management
overhead where you have to keep track of which kind of storage is connected to which host.
The solution to this is shared storage, where all hosts in your environment see the same storage, the same
file system and as such the VM files. So, if a host were to crash, you can quickly power on a VM on another
host without migrating any VM data, since the files are always accessible to every other host. And the storage
management is made simpler since you have it centralized under a single interface. Shared storage devices
for storing VM data are called SAN (storage area network) storages.
Shared storage is used by most companies, except for the smallest companies that cannot afford a SAN.
There are different protocols that could be used, and here are the ones supported by VMware:
Locally attached
SATA
SAS
SCSI
Shared storage
iSCSI
Fibre-channel
Fibre-channel over Ethernet (FCoe)
NFS 3 / NFS 4.1
SATA and SAS physical protocols are the only ones used today for locally attached storage. SCSI in the list
above is the very old “SCSI physical protocol” with a specific cable which is very hard to find these days.
SCSI command protocol

Before we go further with Shared storage, we need to understand what is SCSI and how it works. In this
context, SCSI is understood as “SCSI command protocol” which isn’t tied to any specific hardware. These
days it’s supported by every operating system and is used essentially everywhere to access any kind of block
storage, such as disks, flash drives and tape libraries.
SCSI is quite simple to understand: what you see over the SCSI protocol is some array of data. If you have a
3 TB physical disk connected to a system, then you get an array from 0 to the 3 TB mark (but in bytes,
rather). And the two most common operations are:

Go (seek) to a certain byte offset and write some number of bytes of data
Go to a certain byte offset and read some number of bytes of data.
For example, you can go to offset of 30 MiB from the beginning (31457280) and write 1 MiB (1048576) there.
This is in fact everything that you need to work with some storage device. Everything else — such as partition
management, volumes, file systems and files and folders — is handled on the higher levels by different
modules (drivers) of some operating system. As with most things in computer science, everything operates on
some level of abstraction.
For example, if you save a file in Notepad, this results in a series of write operations to a specific file on
NTFS; the NTFS driver knows where the exact blocks are for that file and converts them to absolute values
within a partition. The partition manager will convert the values to absolute values within the whole disk, and
in the end, they are converted to basic SCSI commands described above.
Now, so far, we’ve been talking about a single (3 TB) disk. What if this wasn’t a single disk though, but a
RAID-controller to which multiple disks are connected? We could imagine four 3 TB disks in a RAID-10
configuration, and that would result in a disk with 6 TB of space. You could call this a virtual disk of sorts. In
this case the RAID configuration is hidden away from the SCSI protocol, and SCSI simply sees a 6 TB disk.
So, if a SCSI write happens, then the RAID controller will figure out specifically to which physical disks to
write this data, and what offsets. SCSI isn’t concerned about that.
Here using term “disk” becomes somewhat incorrect, and the more general fitting term is LUN (Logical Unit
Number). Basically, any virtual or physical storage device of any size will be considered a LUN. The “number”
part comes from the fact that a single connection may yield multiple different LUNs, and they will be
numbered, starting from #0.
Of the shared storage protocols, iSCSI and Fibre-channel are block protocols, so they also utilize SCSI
commands and you work with disks/LUNs. NFS is a file protocol (like CIFS/SMB) so it works completely
differently, with files and folders. Fibre-channel over Ethernet isn’t used these days at all.
iSCSI
Understanding iSCSI is very simple now that you understand SCSI. iSCSI is simply SCSI commands that are
encapsulated into TCP/IP packets and sent over a regular Ethernet network.
You need to connect your ESXi hosts and your SAN storage to the same network segment, via an Ethernet
switch. Every ESXi host is a “client”, and SAN becomes an iSCSI “server”. Once the connection is
established, ESXi will see one or multiple LUNs that are presented on the SAN storage.
To perform a read, ESXi packs a SCSI read command into TCP/IP packets and sends that to the SAN, where
SAN will unpack the data and understand the SCSI command. It will then read the requested amount of data
from the actual physical disk(s), pack that data into TCP/IP packets and send it back to the host. The host will
then unpack the megabyte and do with that data whatever it needed (in most cases it will be a request that
originally came from a VM to read its part of its own virtual disk).
Instead of the client and server, different terms are used, respectively: initiator and target(s). In our case
ESXi has an iSCSI initiator (which is software, and is implemented in vmkernel), and it connects to target or
targets on the SAN. A single target may resolve to one LUN, or to multiple LUNs, depending on the storage
vendor and settings.

Every member of an iSCSI network, be it an initiator or a target, has a unique identifier called IQN (iSCSI
Qualified Name). An example of an IQN is iqn.1998-01.com (http://iqn.1998-
01.com) .vmware:spbsupesx05-2f0eb664. The domain suggests which company/vendor is the one that
created this initiator or target. To connect to a target, you need to specify: IP or hostname of the target
storage system, TCP port, which defaults to 3260, and the target name.
To find the target IQN you need to first create a volume out of physical disks on your SAN storage, and then
export that volume. The IQN is typically automatically generated, and you copy-paste it from your SAN
control panel.
To configure iSCSI, you go to Host > Manage > Storage > Storage Adapters. You may see multiple SATA
and SAS adapters. These are either directly a part of the server motherboard, or a separate extension card
that was additionally installed on the server. You’ll also find the iSCSI Software Adapter – again, this is not a
physical device but simply implemented in software in the vmkernel. Here you can configure the targets on
the Targets tab. You can add them one by one under Static Discovery, or add your storage to the Dynamic
Discovery list, and the Static Discovery list will periodically get automatically populated, if an iSCSI Portal
is available.
Once the targets have been added, you should see the LUNs. From this point, you can go the Datastores
view and use one of the added LUNs to create a datastore, which is essentially a LUN that is formatted into
VMFS file system, where VM files can be stored.
Things to consider when using iSCSI:
The network has to be at least 1 Gbps, and the more the merrier. Otherwise if you have 100 Mbps,
then the host — and in turn the VMs on it — would only operate with disks at maximum theoretical 12
MB/s which is of course terribly slow and unacceptable.
You need a dedicated network for iSCSI. Say, you have massive production traffic going on the same
segment, then throughput and latency of the iSCSI traffic will be reduced, and your overall disk
performance on the host will also go down.
Packet loss or an overcommitted switch can introduce additional delays, and this will negatively affect
the I/O performance. The latency of 20ms is considered to be already quite high and is a cause for
concern.
If a network cable is pulled, or the switch goes down, you get disconnected and all storage I/O stops.
Your VMs won’t crash, but they will be put into Paused state until this is resolved. Of course, this is not
acceptable, so to prevent this you always set up at least two paths, via different network ports, through
a different switch going to the SAN storage. This rule actually applies to any kind of important network
or any system where you need to avoid a single point of failure.
iSCSI requires no special hardware – all you need is your typical networking equipment, and that’s all. So,
iSCSI is easily implemented in software and its initiator and target implementations exist for all OSes. You
could even implement your own.
For example, you can add your iSCSI target to the iSCSI Initiator that comes with desktop Windows versions.
Once added, you’d see that LUN or LUNs in Disk Management, and format them if you want. But your
Windows wouldn’t understand VMFS, and also ESXi doesn’t understand NTFS. However, both would see the
same raw disk/LUN data.
iSCSI can also be hardware accelerated with a designated iSCSI HBA (host bus adapter), which is essentially
a networking card that performs iSCSI packing/unpacking on its own chip. This way, CPU cycles on an ESXi
host can be saved and used for something else (to run VMs).

Fibre Channel
The physical media by which the data is transported here is different, it’s the fibre channel cables that transmit
light. The cables are distinct and typically of orange color.
To set this all up, you need special hardware, so that’s an additional investment. You’ll need to install a Fibre
Channel HBA (networking card) on your ESXi hosts, you’ll need your SAN to support FC (which is quite
likely), and an FC switch in between. You could connect directly, without a switch, but then you’d quickly run
out of ports. And you’ll need to purchase the cables, of course.
https://en.wikipedia.org/wiki/Fibre_Channel_switch#/media/File:ML-QLOGICNFCCONN.JPG
(https://en.wikipedia.org/wiki/Fibre_Channel_switch#/media/File:ML-QLOGICNFCCONN.JPG)
These networks work entirely differently from Ethernet. However, in the end it’s possible to, again, transfer
SCSI commands over this media and communicate with the storage.
For fast reliable networking in the past you would definitely go with FC, but these days iSCSI has become
very good with increased Ethernet speeds.
We have no FC in our labs, but the configuration is even simpler than with iSCSI. If you have an FC HBA then
you’ll see it in the Storage Adapters, and if everything is already connected configured hardware-wise, then
you should see the exported LUNs there, which then can be used to create VMFS Datastores.
NFS
This is not a block protocol, it’s a file protocol, much like SMB/CIFS. All the operations in NFS deal with files
and folders. You can see the file and folder structure, create, rename and delete folders and files, and you
can read or write a portion of a file from some offset within that file. You can also see how much space is in
total and how much of it is free.
What you don’t see is what kind of storage these files are stored on, since this does not concern the NFS
protocol.
The NFS protocol works over TCP/IP. To set this up, you configure a volume on your SAN, format it into some
file system and then export one of the folders on that file system. Your SAN becomes an NFS server. ESXi
will be an NFS client. To connect, you need specify the host name or IP address of the NFS server, and the
folder name. TCP ports are always default or dynamic. On ESXi you add an “NFS share” via the New
Datastore wizard. No Storage Adapters or LUNs are concerned in this case, that’s why you go there directly.
This protocol is also done in software like iSCSI, so you can easily set up an NFS client or an NFS server on
any modern OS, or even write your own. However, NFS hardware-accelerated networking cards do exist as
well.
NFS 3 and 4.1 are entirely incompatible yet serve the same goal. NFS 3 is simpler and you need to provide
root access for ESXi for a share to be mounted. With NFS 4.1 you can use Kerberos authentication for proper
permissions and security.
In the end, what you get is a Datastore, and in some ways it doesn’t matter, whether it’s a VMFS one (from
locally attached storage, or from iSCSI or FC connections), or an NFS share. The host will figure out which
transport needs to be used to deliver the data to the files stored there.
Storage devices
SAN (Storage Area Network) are expensive devices, installed to a server rack, where you install multiple
disks, which can then be formed into a RAID of some supported type, and then exported to be accessible
over some protocol such as iSCSI or Fibre Channel.
They are designed to be reliable, to have great performance and with support of a wide variety of protocols.
For these reasons this is where VM files are stored. The storage system is expected to withstand the
cumulative workload of a myriad VMs you may be running in your environment (but it does of course also
strongly rely on disk performance). Also, SAN devices are very expensive.
SAN storage systems may have custom useful features, depending on the model and vendor. One such
example is Storage Snapshots, which allows you to create snapshots of volumes (LUNs), to be used for
backup or restore. SANs are very complex devices and run on some operating system which is always
custom and Unix-based. To manage the system, you would typically use some web interface or a separate
application.
HP 3PAR as an example: https://i.ytimg.com/vi/pFT4-Ic7g8A/maxresdefault.jpg (https://i.ytimg.com/vi/pFT4-

Ic7g8A/maxresdefault.jpg)
NAS (Network Attached Storage) boxes are smaller, cheaper storage systems. Here you also insert hard
disks to be formed into RAIDs, but they are not designed to withstand serious workloads or provide you with a
multitude of protocols. NAS is a common place to store various files, including backups. Many customers use
an SMB share on a NAS device as a repository for Veeam Backups. There are home NAS boxes for storing
movies etc., but the enterprise versions are more serious.
vCenter
At this point we have at least one working ESXi host with storage connected, and VMs running on it. You will
then install a second and a third host and so on. Yet, these hosts, even while working with shared storage, do
not form a single functional unit and have no “knowledge” of each other. For hosts to work together and
provide you with certain features (listed later), they need to be formed into a cluster.
With vCenter you can join your hosts into a cluster, and from that point hosts can give you improved
availability, better balancing, and more. Furthermore, vCenter simplifies management. With 3 hosts, you’d
need to use 3 instances of the vSphere Client to manage them. vCenter serves as a single aggregate view
instead, where you can see all hosts and their objects at once.
vCenter is just a management server which can be virtual or physical. If vCenter crashes, the VMs will still
running normally, but what you would lose is the ability to reconfigure the cluster.
Initially when you have just installed vCenter, its inventory would be empty. First, you’d need to create a
Datacenter. This is not a functional, but rather a logical unit, typically some geographical location or an office.
So, if we have an office in Saint Petersburg, that’d be one Datacenter, another office in Bucharest, and that’d
be another Datacenter. These datacenters share nothing so that makes sense.
The next step is to create a cluster, and this is a functional unit that has certain important features. The
cluster is empty at first but then you add your hosts to it by providing the root credentials of those hosts to
vCenter. From that point, vCenter will have full control over the hosts and you will no longer need to log in
directly to those hosts.
From that point in the hierarchy you will see all VMs in your environment, and in the Datastore view you’ll see
all the Datastores, no matter to which hosts they are connected to. The same applies for the Networking view.

Compared to a standalone ESXi, vCenter needs to run a database server, since it has to store a lot more
data than a regular host. First, all the info from every host, and then also all the historical Performance data,
Events and Tasks, for at least 1 year, by default. You can see Performance metrics for almost every object in
the vSphere Client.
There are two options to installing vCenter. The first one is on Windows, and this can be both physical or
virtual. These days you probably wouldn’t want to install a physical vCenter due to the overhead and lack of
virtualization features. You need to download a vCenter installation .iso and go through an installation wizard.
For the database server, you can use the built-in free PostgreSQL database, but it limits you to only 10 hosts
or 100 VMs maximum. So, you would probably need to purchase MSSQL or Oracle. But note that VMware
plan to discontinue the Windows version in a future vSphere release.
The better, recommended option is to install vCenter Server Appliance (VCSA), which is a specially crafted
Linux VM, installed and configured from a template, downloaded from the VMware website. When this VM
boots, its only purpose is to be a functional vCenter with all unnecessary extras removed. Here you can safely
go for PostgreSQL as the limitation does not apply here. VCSA is essentially free, while to install on Windows
you must purchase a Windows license and a database engine license as well.
From the user/vSphere client perspective, there is no discernible difference between the two installations.
If you want to run virtual ESXi and virtual vCenter in the lab, keep in mind that ESXi needs 4 GB RAM
minimum, and vCenter requires at least 8 GB.
vCenter internals
The key service running on vCenter is called vpxd. This is analogous to hostd on ESXi. Now that you’re
doing management via vCenter, all API/user requests will be processed by vpxd. When you add an ESXi
host to vCenter, vCenter will deploy to that host a new service called vpxa (which stands for “vpx agent,” or
vCenter agent). Now, when someone for example requests to create a VM on that host:
1. Request reaches vpxd.

2. vpxd understands which host is supposed to register that VM and forwards the request to vpxa on that
host.
3. vpxa will either perform the request on its own, or forward the request to hostd.
4. The result (success, or failure, together with the reason for failure) is then propagated back to vpxd
and the user.
Single Sign-On is responsible for all authentication on vCenter. Every time you log in, SSO will check
whether the credentials are valid. SSO allows you add your Active Directory domain as an additional identity
source and therefore use the AD accounts and groups. In this case, SSO will check with AD whether the
account is allowed to log in, and to which groups it belongs to.
vSphere Web Client is also part of the vCenter installation, but in this context, is understood as the server
part, the HTTP server that returns the web content.
vSphere vs vCenter vs ESXi

ESXi is a product, an operating system that you can install, that has a version and a concrete build number.
E.g. ESXi v6.5.0 build 5969303. The same is true about vCenter. But vSphere is not a product, not a
program that you install — it’s a family of related products, ESXi and vCenter included. So, if you have ESXi
and vCenter v6.5, then you could say that you have vSphere 6.5 installed.

vCenter/cluster features
These features are only available when you have a vCenter and a cluster. These are the core features, which
have existed for a long while now and are widely used.
vMotion allows you to migrate a VM from one host to another, without any interruption/downtime. For this you
need the target host to have access to the datastore where the VM files are stored. You would use vMotion
when you want to balance the load in the cluster, or when you’d like to shut down or reboot the host (for
maintenance, ESXi patches, firmware update), and you wouldn’t want to shut down the VMs with it.
The operation involves copying the memory and CPU states from one host to another. If the hosts
architecture isn’t completely identical, then this will not necessarily work. If you use Intel and AMD on the two
hosts, then it’s plain impossible. But even Intel of different generations can be incompatible due to subtle
differences, or a missing CPU instruction. To avoid this problem, you can enable Enhanced vMotion
Compatibility (EVC), that will force the VMs to run on the required compatible level that disables the
incompatible features of hosts’ CPUs. Having vMotion is very likely more important than some minor
performance benefit.
Storage vMotion is used to migrate the VM files from one datastore to another, while the VM keeps running
on the same host. The target datastore could be of any type: VMFS, NFS, VSAN, etc., as long as it’s
connected to the host. Again, there’s no interruption, the process is seamless. First, the files are copied and
then the host ensures that the files are kept in sync. Once done, the VM is switched to the new files, and then
the original copy is deleted. svMotion can be used to free up space, to reduce the load, or for situations when
you have to shut down your storage.
Distributed Resource Scheduler (DRS) lets you balance the load in the cluster among the hosts. It will give
you recommendations as to which VMs should be moved to which host to make the cluster more balanced,
and, depending on the settings, it will also apply them automatically. The only metrics used to generate the
recommendations are the used/available CPU and memory. Recommendations, when applied, result in
vMotion operations added to the queue, to migrate the VMs.
In the vSphere Web Client, you can go to Cluster > Monitor > vSphere DRS to see the recommendations,
apply them and see the current CPU/RAM usage on all hosts by all VMs. The recommendations are also
applied or shown when a VM is powered on by a user, so that the VM lands on the most suitable host.
Another feature that is part of DRS is affinity and anti-affinity rules. Affinity could be used to force two VMs to
always run on the same host, to have the best communication speed between them. Anti-affinity could
ensure the opposite, so that one host failure doesn’t lead to both machines failing too — this can be useful for
cluster nodes, e.g. two Domain Controller servers.
Storage DRS is the same, but for Datastore Clusters, which have to be formed out of multiple Datastores.
Storage DRS balances the datastore cluster based on the available space and datastore latency history, and
uses Storage vMotion to move the VM disks accordingly.
High Availability (HA) is aimed at reducing the VM downtime in case of a disaster. If one of your hosts
crashes into a PSOD, turns off or hangs, or becomes completely isolated for some reason, then High
Availability will detect that issue and automatically register and restart the affected VMs on other hosts.
Without it, you’d have to do this by hand, which would definitely take longer than with HA, which reduces the
downtime to maybe 5-10 minutes (as long as the VMs need to start). Of course, the memory state of the VMs
is lost since the VMs crash along with the host, but the downtime is reduced to the minimum.

When HA is enabled, all hosts in the cluster start performing a continuous heartbeat test (essentially a ping)
to each other on the management network. Also, every host starts running a small database that holds
information about which VMs run on which host in the cluster.
If one host stops responding to the heartbeat calls, then something’s gone wrong and the host may have
crashed, for example; however, this alone is not enough evidence, since it is possible that only a networking
cable was pulled (on the network between the hosts). What the rest of the hosts do then, is check the
/.vSphere-HA/ folder on a couple of the designated datastores. Every host is supposed to be continuously
writing some system data there, and if it stopped doing that, then it’s probably no longer functional. Once this
has been established, the hosts will start the failover: register the affected VMs and start them, the new hosts
determined based on the settings (and DRS, if enabled, will help here).
You could have a separate empty HA-designated host for this, or have a given percentage of CPU/RAM
resources on every host reserved for this purpose.
Another technology considered to be part of HA is called VM Monitoring. If a guest OS hangs due to

whatever reason, then the host is able to automatically restart it. To determine a hang, ESXi periodically pings
the VMware Tools (discussed later) and also checks whether the virtual SCSI controllers perform any I/O on
the virtual disks. If the Tools are not responding, and there’s no I/O registered, then the VM is forcibly
restarted.
Fault Tolerance (FT) is a technology that prevents any memory and data loss in case of a host failure.
Historically there are two versions of FT: the current one, and the legacy one. The legacy was in vSphere 5.5
and before, and had many limitations.
FT is enabled for a given VM, and FT will first create a copy of that VM on another host, and then keep both
the primary and secondary VMs in complete sync. They run in lock-step so there’s no data difference. The
same is done for the VM files: they are copied and kept in sync on another datastore.
Should the host with the primary VM go down, the cluster will notice that and then switch the execution to the
secondary copy. There may be a short downtime, but no data in memory is lost. The same procedure
happens for the datastores if needed.
FT works like a policy, so if the host went down, then the policy requirements are no longer being met. FT will
immediately find another host, if one is available, and replicate the secondary (now-primary) VM to that host.
Current FT does have some adoption today, while almost nobody used Legacy FT due to these limitations:
no VM files are copied, only the CPU/memory;

no more than 1 vCPU in the VM;
no snapshots, and as such no backups.
This last point is the golden rule: to make a VM/disk backup, you need to be able to make a snapshot of that
VM/disk. Otherwise, no backups are possible from the hypervisor level. You could only find some workaround
by backing up data from within the guest OS.
Current FT supports up to 4 vCPUs, and supports snapshots, and as such Veeam also can make backups of
FT-enabled VMs.
Licensing
Not all of the features listed above are available to all the customers. This depends on the license that they
have purchased. Sometimes we may ask a customer to migrate a VM or its files for troubleshooting, but you
cannot assume that they necessarily have vMotion or Storage vMotion.
There are 4 paid editions of VMware, with more features available to the more expensive licenses. ESXi can
run without a license for 60 days without any restrictions, but then you’ll have to install a license.
There’s a special case called “Hypervisor”, unofficially known as “Free ESXi”. This license does not even
support vCenter and doesn’t expose some of the APIs that Veeam needs to perform a backup. As such they
are not supported by Veeam. But any paid license is.
Authentication and ports

If we look at a standalone host first, then the root account is the first one created and it has complete control
over the host. You can then add additional users with restricted permissions.
When you connect with the legacy vSphere Client, it connects to ESXi (or vCenter) on the HTTPS port, TCP
443. This is where the vSphere API is served, and it is used by the client to display the VMs, their properties
and everything else. Other applications, Veeam included, also use the same vSphere APIs to work with the
VMs and all other objects on ESXi/vCenter.
If SSH is enabled on ESXi, then you can use an SSH client to connect there, and use the root account to log
in. This is rarely needed, commonly only for troubleshooting. You can browse the file system, and if you cd to
/vmfs/volumes/, you’ll see the same Datastores that you have on the server, since they are simply mounted
file systems (VMFS or NFS). If you enter a datastore folder, you’ll see that it’s actually a symbolic link to a
folder with a GUID in name, e.g. /vmfs/volumes/594bc53e-fec19f69-331b-005056b672a6. There you’ll see
VM folders and files. This will be the same content that you see in a Datastore Browser of the vSphere Client.
You can use the common Unix commands. One common tool, analogous to top on Linux is esxtop, which
shows CPU, memory, network and disk usage in realtime. This is rarely used in our practice, but it’s the best
for realtime monitoring. You’ll see hostd and vpxa processes there among others, and VMs will be listed as
separate processes as well.
When you attempt to download or upload a file to/from a Datastore in the Datastore Browser, a TCP
connection to port 902 to the host will open, used for the Network File Copy (NFC) protocol. With this you
can get any file visible to a host, and the data will be first fetched by the host, and then sent over to the client
that downloads the file. Veeam uses the same NFC protocol to download the VM files (.vmx, .vmxf, .nvram)
and also the disks, when NBD transport mode is used, so if for any reason this TCP connection cannot go
through (due to a firewall for example), the backup will fail. This applies also to restores and almost any other
operation.
NFC connection is an important part of our backup, indeed, without it, the very first phase where we obtain
VMX files (configuration info about the VM) is going to fail. You can check the connection by simply logging in
to VCenter, accessing the folder with VM - Download to Desktop - any small file, like VMX. NFC stream is
established for that and connection is tested.
When installing vCenter, you specify the default full-permissions account for it, which is by default
administrator@vsphere.local (mailto:administrator@vsphere.local). But you can customize both parts,
before and after the ‘@’ character. The latter part is going to be the local domain in the SSO; you shouldn’t
use your existing domain there, and the default vsphere.local is always a good choice. This account will have
complete control over vCenter, all added hosts and, therefore, complete control over your virtual
infrastructure. When troubleshooting vSphere permissions, you may want to try to use this account
temporarily to narrow down the issue.

You can continue using the local vSphere domain, but it’s more typical to add another source of
authentication, such as an Active Directory domain. This will save you from creating tons of duplicate users or
groups.
Tags
Tags and attributes allow you to attach metadata to objects in the vSphere inventory to make it easier to sort
and search for these objects.
A tag is a label that you can apply to objects in the vSphere inventory. When you create a tag, you assign that
tag to a category. Categories allow you to group related tags together. When you define a category, you can
specify the object types for its tags, and whether more than one tag in the category can be applied to an
object.
For example, if you wanted to tag your virtual machines by guest operating system type, you can create a
category called operating system. You can specify that it applies to virtual machines only and that only a
single tag can be applied to a virtual machine at any time. The tags in this category might be Windows, Linux,
and Mac OS.
For Veeam to be able to backup VMs by Tags - Vcenter must be added to our GUI using
FQDN exclusively!
The following can be executed to check FQDN stored in VCenter MOB. It must be identical to what you see in
Veeam GUI
Managed Object Browser (MOB)

MOB is a web interface that allows you to inspect and act upon objects available in the vSphere
infrastructure. In vSphere, almost everything is an object: a VM, a Host, a Datastore, a snapshot, even a task.
Every object has a specific type (a category), a unique name, a set of fields and methods.
To get to MOB, you open your browser on the following address: https://vcenter/mob/ (https://vcenter/mob/)
or https://esxi/mob/ (https://esxi/mob/) . You’ll need to put in your valid credentials.
Every page is a view on a given object. Its name and type are listed on top. The topmost object is
ServiceInstance of type ServiceInstance. You can see Properties, which are either links to other related
objects, or fields of data (“serverClock” in this case). Below you can see Methods, which are actions that you
can perform on this object.
The ServiceInstance object isn’t interesting, so to find objects of interest to us, we go to content, then ha-
folder-root, and there you’ll find the datacenters. If you’re looking at the MOB of a ESXi host, you’ll see ha-
datacenter, which is like the host itself (since proper Datacenters are only possible with vCenter). When
looking at vCenter MOB, you’d see the list of actual Datacenters that you have.
To get from Datacenter to VMs, you enter some Datastore object, and then you’ll finally see the list of VMs
related to that Datastore. At this point you may notice that Datastores and VMs have a unique ID and then
also a user-friendly name, e.g. on an ESXi host: “95 (W2012-nfstest),” where 95 is the ID of the VM, and

W2012-nfstest is the VM name. The object ID is the primary and the really important value, while the name
can be easily changed and really doesn’t have much importance. If you rename the VM, the ID will stay the
same (if you then refresh the MOB page you’ll see how only the name has changed).
If you look at the properties of a VM and dig deep enough you can basically find all of its properties that you
can get in the vSphere Client, and then some. Basically, all of the virtual hardware details, features and flags.
Methods, too, allow the same actions you can do in the vSphere Client, but at the more lower, API-like level.
MOB is in fact pretty much the same as vSphere API, but designed for humans. Typically, it is only used for
troubleshooting though.
As an example, you can create a snapshot by issuing the CreateSnapshot_Task method. You’ll see an
HTML form with four fields: two strings and two binary ones. And if you were to try and create a snapshot in
the vSphere Client, you’d in fact see the same four fields. Now, if you fill in the name and description and fill
the binary fields with 0, then Invoke Method, you’ll notice a new snapshot on that VM, and also a relevant task
“Create virtual machine snapshot.” That task is also what is returned by that method in MOB, and you can
inspect its properties, such as the state and progress (typically Success, and 100% at this point).
Now, in the previous example we had a look at a VM from the ESXi perspective. But it we now go to the MOB
of a vCenter that controls that host, we’ll be able to find that very same VM, but with a different ID, e.g. “vm-
467.” That’s because vCenter keeps its own database, and the number of objects is larger there. vCenter in
fact gives all objects the IDs in the format <type>-<number>, where number is unique across all objects. Also,
naturally, all methods that you run here will be initiated from vCenter.
These unique IDs are properly called Managed Object References (moRef), or, when referring to VM objects,
vmRef. An important note here is that Veeam, among other applications, in most cases keeps track of
vSphere objects based on the IDs, not names. If you remove a VM from inventory, and then register the same
.vmx again, the VM will have a completely new ID, even though it’s the very same VM files. Veeam backup
jobs would lose track of it, so you’d have to re-add that VM to the job. If customer re-installs vCenter, then all
IDs are assigned from scratch, and Veeam will lose track of all objects altogether. Since vmRef on a vCenter
and on a host are different for the same VM, then Veeam would treat this VM as different instances, when
added via vCenter vs. when added via a standalone host.
You can Remove from Inventory, or Delete from Disk. The former removes the VM registration, while
the latter also deletes all the files on the datastore. If you have VM files lying around, you can register the
VM again if you right-click the .vmx file in the Datastore Browser and use Add to Inventory.
Situations where vmRef gets changed include all scenarios where a VM is registered: during restore,
replication or clone. One exception is vMotion – in this case the vmRef on vCenter will stay the same.
vmRef values are needed in some cases, such as when you need to use the VixLibDiskSample tool. You
won’t see vmRef values in the vSphere Client anywhere, so you’ll have to go to MOB for that. Also, vmRef
are very common occurrences in Veeam logs.
As noted above, MOB is for humans. Programs using SDK must go to the https://vcenter/sdk/
(https://vcenter/sdk/) address.
VM files
A virtual machine is just a bunch of files, handled by the hypervisor. In most cases, all the files are stored in a
single folder with the VM name on some datastore, but for larger VMs you can move disks to another
datastore to save space and balance the load.

.vmx is the “primary,” configuration file. It’s a small text file that includes all the virtual hardware information
and certain properties of the VM, such as: how much RAM does it have, what virtual disks are attached, or
whether FT is enabled or not. .vmx may have a link to a .vmxf file which is an auxiliary config file sometimes
used by vCenter, but in our practice we never troubleshoot anything related to it.
Both files are important if you want to restore the VM — otherwise there’s no way to register it automatically,
so both files are included in a Veeam backup. But even if you were to lose the .vmx file, you can simply create
a new VM maybe with a bit different configuration, and then mount the existing disks to it.
VM disks are formed of two separate files: .vmdk and -flat.vmdk. The .vmdk file is a descriptor, a tiny text
file describing where the flat file is located and how big is the disk (in sectors, each sector equaling 512
bytes). The -flat.vmdk file is the actual binary data of that virtual disk. In case of a thick disk, this file will be
of exactly the same size on the datastore, as the “physical” disk it represents for a guest OS. And the
contents of the -flat.vmdk file are 1:1 to what the guest OS can “see” on that disks, with the same data at the
same offsets. This isn’t true for thin (sparse) disks, which don’t store empty portions of the disk.
Naturally, VM disks are the most important part of a VM, and as such both files for every disk are put in the
backups.
One oddity one may notice is how the datastore browser only shows a single entry for a disk, while it’s
actually comprised of two files, and you’ll see both files if you connect over SSH. This is probably done for
convenience. If you attempt to download the disk, it’ll first fetch the descriptor, and then the flat (always
translated to thick format).
The disk described above could be named a regular, “base” disk. But there also delta (incremental) disks,
which appear if a disk has at least one snapshot. The descriptor has a suffix, e.g. -000001.vmdk, and the
data file is named e.g. -000001-delta.vmdk. On its own, such disk would be useless, since it only contains
changes, a difference to its parent disk. Parent disk is either a complete base disk, or another delta disk
(which has another parent).
If the base disk contains data ABCDEFG, then you make a snapshot and the OS writes some more data so it
becomes ABCDEFG, then the relevant delta disk only contains BCF. Without the base disk it’s just a
fragment.
If you have any delta disk files, then that disk is definitely on at least one snapshot. Veeam uses snapshots to
make backups, but does not place any delta disks into the backup, only the consolidated state under the
current snapshot.
The .nvram file is a small binary file that stores the BIOS settings of a VM. Like a physical computer, a VM
has a BIOS (or even UEFI if you want that), and its settings need to be stored. Instead of a battery to hold the
NVRAM data, here it’s a file. This file is of little significance, however BIOS may have a custom boot order of
VM disks, so Veeam puts this file into the backup to preserve those settings. If you lose this file, it’s not a
problem at all — a new one will be created by the host automatically on the next boot of the VM.
The .vmsd and .vmsn files only exist when there are snapshots on the VM. .vmsd is the snapshot tree, and
.vmsn holds some snapshot data, including memory if you choose to save it to a snapshot. Veeam never
uses memory snapshots, and we don’t put these files into the backup.
The .log files are text files that contain the VM activity, from the perspective of the host – such as when the
VM is restarted, or new virtual hardware is added or removed. The logs are written by the vmx process, so
these logs are only written to when the VM is running. If you want details for VMs that are turned off, look for
hostd.log. A common case is when something goes wrong with a VM during snapshot removal, and

customers blame Veeam for it. All failures during snapshot removal are due to ESXi issues/bugs or storage
issues. You can investigate vmware.log files for the root cause and advise the customer to contact VMware
support with that evidence. Logs files are not put into Veeam backups.
Changed Block Tracking

-ctk.vmdk files are used for the VMware technology called Changed Block Tracking (CBT), which is
designed for backups solutions — it improves the backup time by providing you with the information about
how much data on a virtual disk has changed.
Suppose we make a backup of a disk with Veeam. The first ever backup will be a Full backup. Veeam has to
read the whole disk from start to finish, and put that data into a backup file (.vbk). The next time we need to
make a backup we know that not all data on that disk has changed. In fact, it is estimated that on an average
server during 24 hours about 10% of disk data is changed (this depends on the type of server of course). So,
it would be ideal to read only those 10% and put them in an incremental backup. And this is exactly what CBT
allows — it’s an API that Veeam (or any other backup solution) can query to obtain information about what
blocks have changed, so the rest of them can be skipped during backup. This tech is crucial for efficient
incremental backups.
So, when CBT is used, Veeam only needs to read certain areas of a virtual disk which are indicated as
changed, and this reduces the overall load on the storage infrastructure, dramatically reduces the backup
times, and the incremental backups are of course smaller. But it’s important to note here that even if CBT isn’t
working or disabled (for whatever reason), then the incremental backup size isn’t affected, since Veeam only
puts blocks into the backup that have in fact changed. Suppose CBT isn’t working – then Veeam fails back to
the straightforward way of having to read the full disk again. But the incoming data is always split by Veeam
into blocks (which default to 1 MiB in size), and for every such processed block an md5 hash sum is
calculated. If such hashsum is already in the backup chain somewhere (i.e. in the full backup that was
created yesterday, in our example), then it’s skipped, and simply a pointer is set in the backup to read the
data from a previous backup file. No matter whether CBT is enabled or not, this mechanism (known as
deduplication) is used, and there will be no identical blocks in the backup. (By the way it’s extremely unlikely
that there will be an md5 collision for two blocks with random data). So, without CBT Veeam reads many
blocks that haven’t changed from yesterday, and they will be skipped. The end result is the same as with CBT,
but Veeam had to read the whole disk.
If CBT stopped working, there’s a very popular KB that describes how to do a “CBT reset”:
https://www.veeam.com/kb1113 (https://www.veeam.com/kb1113)
It is possible that CBT will return incorrect information. This means that incomplete data will be put into an
incremental backup file, and result in corrupted backup. This is the silent type of data corruption since you
will only find out about it when you restore the VM and power it on. The end result is a VM with corrupted
files, file systems, or even potentially an unbootable Guest OS due to a damaged driver file.
Imagine the disk has recently changed as follows: ABCDE > ABCDE > ABCDE > ABCDE. You made a full
backup (ABCDE) before, and now want an incremental backup. CBT erroneously reports that only B and C
have changed, so the end result is ABCDE. But at no point the disk was in this state! So, B and C are new,
but D is old, so this is inconsistent and corrupted.
Of course, CBT reporting incorrect data isn’t normal. It always happens due to ESXi bugs. Unpatched 5.x
versions can do this after a disk was resized (https://kb.vmware.com/kb/2090639
(https://kb.vmware.com/kb/2090639) ), and unpatched 6.0 can do this virtually at any point
(https://kb.vmware.com/kb/2136854 (https://kb.vmware.com/kb/2136854) ). As of September 2017, all
known CBT bugs are fixed if you have the latest patches installed, so it’s always a good practice to have them
installed. The thing is, Veeam always assumes that CBT data is always correct, and also has no way to verify
its correctness – otherwise we’d just need to read the whole disk, which ruins the whole point.
Customers often open cases about these issues, when they see that their restored VM doesn’t boot correctly.
You should advise to install the latest patches and reset CBT for all VMs, since the CBT data (in the -ctk files)
isn’t retroactively fixed. Alternatively, you can temporarily disable CBT in the backup jobs. Once CBT has
been fixed, you only need to run another backup session and the latest restore point should be consistent.
CBT also helps during full backups of Thick disks. If you query “changeID *”, then CBT returns the areas of
the disk that were changed at least once. If you have a 3TB disk where only 1TB was used so far, only that
portion of the disk will be read in that case. The rest of the disk is just zeroes (if Veeam reads zeroes, by the
way, they are just compressed into nothing, marked as sparse blocks). Your Full backup also becomes more
efficient. But this also means that if you have CBT corruption, then even your full backups may be at risk.
The -ctk.vmdk files are small binary files that contain the history of changed blocks, but they are of no
importance in our backups, so they are not placed there.
Snapshots
Snapshots are very important for us, because they are required for making a VM backup. A snapshot is a
persistent, consistent saved state of VM. It can be used to roll back to a saved point in time, such as when
you want to install an important update and would like an easy way to go back in time, as if nothing happened
on that server. Or, they can be used for backups since you can read the data from the snapshot, and the data
won’t change for as long as the snapshot exists.
Reading the disk as is, while the VM is running, won’t result in a consistent backup since the disk contents
are being updated in real time, and backing up the whole disk doesn’t happen immediately. So, without a
snapshot the earlier blocks of disk data would be older, and the latter blocks would be more fresh, which
would result in data corruption. With snapshots, you can read from one and it won’t ever change. Once you’ve
completed the backup, you can – and should – remove the snapshot.
There are different possible ways to implement snapshots, and the one used on ESXi is known as redirect-
on-write, also known as “delta” snapshots, since delta disks are used. When there are no snapshots, the
writes happen directly to the only base disk. With a snapshot, a delta disk is created (initially empty), and from
that point all writes (that happen due to the running guest OS) will be redirected to the newly created delta
disk, and the base disk is kept intact. This allows a backup application to read the base disk and put it into
backup.
Then the final step is removing the snapshot when you’re done with the backup, which means that the state
that you’ve saved before is no longer needed. When instructed to remove the snapshot, the host will
consolidate (merge, inject) the delta disk back into the base disk and, once complete, remove the delta disk. If
you had a base disk ABCDEFG, and after some time it has accumulated delta disk with changes BCF, then
when the snapshot is done removing, the base disk is ABCDEFG.
It is important to understand that snapshots are not backups. Snapshots mechanism relies on a potentially
complex tree of disks, and should you lose the base disk for any reason, then it’s just gone and snapshots
won’t help you – the delta disks all depend on the base disk. A backup is a complete, restorable copy of VM
data, stored in a different place.

Having a VM running on a snapshot for a prolonged time has its issues, and for this reason it’s recommended
to remove the snapshot as soon as it’s no longer needed. E.g. Veeam will remove them automatically once
the backup is complete. A user should remember if they created a snapshot manually, and then later must
remove it. The recommended maximum time is 72 hours. vCenter and monitoring solutions include warnings
notifying about VMs that have been running on snapshots for a while.
The I/O performance of VMs running on snapshots is decreased. The read performance is decreased
due to the fragmentation of the delta disk, and linear guest reads can turn to random datastore reads.
Instead of dealing with a single disk, the host has to jump between two files (or more). The write
performance is also decreased, since delta disks are sparse (Thin) and work slower than regular Thick
disks. Not only the VM performance is affected, but also the backup speed too, so if you have a case
where a few VMs backup slower than the rest, check for snapshots on those first.
The delta disks are continuously growing with the new writes. In theory, a delta disk could grow to the
size of its base disk, if you overwrite all the blocks. In that case the VM would take twice the space.
One should monitor the available datastore space and not let it go down to zero.
Snapshot removal is a complex I/O-intensive and sometimes problematic process, and the larger the
snapshot, the more chances that something might go wrong.
You can have multiple snapshots one after another, the maximum is 32 in “depth”. You can also have multiple
timelines. Create a snapshot (#1), then later another (#2), then roll back to (#1) and since the VM is running, it
creates a new timeline that has branched at (#1). You can then create (#3) and have two persistent timelines.
In practice, it is rare that anyone needs more than one snapshot. The rest of the scenarios is typically just for
testing. With branches, you could for example install different versions of software and evaluate them.
Snapshot removal is a complex process. Normally there should be no issues, just a short barely noticeable
delay (like with vMotion). But, depending on the datastore latency, I/O activity of the VM and version of ESXi,
there may be complications, including:
VM becomes unreachable for prolonged amount of time, until the snapshot is finally consolidated.
There is no way to cancel snapshot removal once it’s started, so you just have to wait until it’s done.
VM process crashes.
VM disk data gets corrupted.
The newer the version of ESXi, the smoother the process. Versions before 6.0 would take a multi-stage
approach for snapshot deletion: new smaller delta disks were created, while the previous one was merged. In
6.0 and newer, a sync driver is used that allows the writes to arrive to the delta disk while it’s being merged.
Many snapshot issues can be reproduced without Veeam, when you want demonstrate it. Simply create a
snapshot, wait for the amount of time it typically takes the backup to complete, then remove the snapshot. It’s
likely you’ll observe the same issue (e.g. the VM becomes unresponsive). Veeam never deals with disks
directly, it only issues API requests to create and remove the snapshots, and the host does the rest.
Virtual Machine compatibility levels

The virtual hardware version of a VM is a simple number, a property of a VM that defines the limits of the
virtual hardware, and certain features. For example, version 11, that only runs on vSphere 6.0 or newer,
allows for maximum of 4 TiB of RAM in a virtual machine. These days it is more than enough, but for example
version 4 only supports 64 GiB, which isn’t that much. As for features, version 10 (vSphere 5.5), for example,
brings GPU acceleration: you can install an Nvidia GPU and then delegate some of its VRAM to a virtual
machine e.g. for whatever 3-D or CUDA purpose.

Every new vSphere release brings a new version, and only that host or newer will be able to run such a VM,
but all previous versions are supported. You need to keep in mind that if you back up from a newer host and
restore to an older one, this will not work if the VM version isn’t supported there. The same applies for
replication to an older version of ESXi.
Upgrading to a new version is very simple and done via the context menu – you’ll need to shut down the VM
though. Downgrading isn’t possible, but you can simply create a new VM and specify the older version.
Upgrade is only really necessary if you want the new features, otherwise there’s no performance
improvement.
VMware Tools
There are two problems inherent to virtualization:
VMs run on virtual (synthetic) hardware, and they may work inefficiently, or not work at all, with that
hardware.
From the host perspective, a VM is just a container, a process, and ESXi cannot intelligently
understand what happens inside: which OS is running, which IP addresses are on a VM and so on. For
the host a VM is just a black box which you can power on, reset, power off and modify the hardware. Of
course, the host can read all of VM’s memory, but understanding what it corresponds to wouldn’t be a
simple task.
VMware Tools solve both of these problems. VMware Tools first and foremost are a set of device drivers for
the virtual hardware encountered on ESXi VMs. If you install Windows on an ESXi VM and open the Device
Manager, you’ll see many devices marked red or yellow. Once the Tools are installed, all devices will go into
normal state. You can check the properties of the Display Adapter, and you’ll see that it’s named “VMware
SVGA 3D”, and its drivers are made by VMware, included as part of the VMware Tools. Without it, you get a
very limited set of resolutions in the Remote Console. Also, the mouse becomes much easier to use in the
Console.
Another example is the network adapters. When you add a virtual NIC to a VM, you have to pick the type:
e1000, e1000e or vmxnet3. The former two are analogous to Intel cards that you can find the real world, they
are quite popular and drivers for them are included with every OS. But vmxnet3 was created by VMware
specifically for virtualization and it doesn’t exist in the physical world. It’s designed to give the best
throughput/performance, but for it to work you need to install VMware Tools.
Now to the part where host has no information about the Guest OS. ESXi exposes two devices to every VM:
“VMware VMCI” Bus and Host devices. It’s a special communication channel through which ESXi and the
VMware Tools are able to communicate. vSphere Client can show you the IP addresses of a VM if you have
VMware Tools installed – for this to work the host periodically asks that info from the VMware Tools via VMCI,
and VMware Tools respond accordingly. Furthermore, you can now shut down or reboot the VM gracefully (as
opposed to immediately, with potential data loss), and this is also done with VMware Tools.
But this channel actually allows you to perform any in-guest operation via the vSphere or the older, now-
legacy VIX API: you can upload a file, run any executable or script, and download a file from the guest OS. All
of this is done in network-less mode – the VM doesn’t even need a NIC. These APIs are used by Veeam
during Guest Files restore, when direct network connection isn’t available. The APIs are slower, but work in
most cases.
Realistically you need to install the Tools in all cases whenever possible. There are some rare OS types
where the Tools do not exist. Installation on Windows is as straightforward as clicking Next a few times,
followed by a reboot. VMware ship Tools for all Windows versions, including desktop and very old ones. On
Linux, it’s strongly recommended to simply install the open-vm-tools package, available in most distros;
there also exists an old .tag.gz bundle which is massively outdated.
VMFS
Virtual Machine File System is a clustered file system created by VMware to format block storage to store VM
files on. “Clustered” means that multiple hosts can access it at the same time, read the same file (unless it’s
exclusively locked), and even write to the same file. NTFS, for comparison, is not a clustered file system, and
you need to add CSV on top of it to make it clustered – otherwise you’ll get data loss.
The most commonly used VMFS version is 5. The only really important thing about it is the file size
limitations: the maximum file size is 62 TB, and as such the maximum VMDK disk size is also 62 TB. In
vSphere 5.1 the limit was way smaller, only 2 TB.
vSphere 6.5 brings new VMFS 6 which natively supports 4K sector disks and SCSI UNMAP, also all delta
disks on it are of SeSparse type.
There is also VMFS 3, but it’s unlikely to be found these days. It had worse performance compared to VMFS
5 and the file size limitations were even stricter. You cannot create new VMFS 3 volumes with the current
vSphere releases.
Raw Device Mapping (RDM)

RDM is an alternative way to connect a disk to a VM. A regular virtual disk is two .vmdk files, as noted
previously. But with RDM you create a LUN on your SAN and then connect it as a whole to the VM, sort of
“passing it through”. The ESXi host will act as a proxy and send/receive all the SCSI commands from the VM
to the LUN and back. This is similar to connecting a USB flash drive into a VM on a desktop hypervisor.
There’s no additional file system / virtualization layer here. Imagine you format that RDM into NTFS, then
dismount it from the VM and connect that LUN to another machine, maybe even a physical one. The new
machine will see exactly the same data. There’s no VMFS, no .vmdk disks to think about.
To add an RDM, you add an RDM disk in the VM configuration and pick some yet-unused LUN. This will
create a .vmdk file on a datastore, but instead of also creating a -flat.vmdk file, the .vmdk descriptor will point
to the actual LUN. And naturally, a VM cannot tell what kind of disk it actually is.
RDMs are rarely used these days, since you lose some – or all, depending on the mode – benefits of the
virtualization. In the past, one reason you’d use an RDM is if you wanted a >2 TB disk in a VM. But this is no
longer a problem. Another reason is to have a shared disk for a Microsoft cluster, but modern clusters are
often share-nothing (Exchange DAG, MSSQL Always On), so that’s not a common case either.
There are two modes in which you can connect an RDM: Physical and Virtual. If you want to change the
mode, you can simply re-mount the RDM in the VM configuration.
The physical mode is very restrictive. In this mode, all SCSI commands are passed through the host, without
any processing. Since VMware snapshots are redirect-on-write, and redirection in this case isn’t possible, this
results in the snapshot feature not available for these RDMs. This in turn means that host-level backups are
not possible (i.e. with Veeam).
In the virtual mode, the host is able to process and redirect the read and write SCSI commands, and this
allows for snapshots. The base disk is a pair of {disk.vmdk => RDM LUN}, and disk.vmdk descriptor has to be
stored on some datastore, in the VM folder. But there’s no additional space on the LUN to store snapshots, so

they also have to be stored on some datastore. A delta disk that appears when a snapshot is created, is a
pair of {disk-000001.vmdk => disk-000001-delta.vmdk} files. When you issue snapshot removal, then the host
will merge the data from the -delta.vmdk disk into the RDM LUN.
Disk provisioning types

When creating a disk, you need to pick the type it will be: either thin, or thick provisioned.
Thick .vmdk disks immediately occupy the space on the datastore that they need. If a disk is 3 TB in size,
then 3 TB will be gone from the datastore. Internally the data of the -flat disk will be exactly the same as what
the Guest will see, on the same offsets. This results in overall good performance of such disks. Linear I/O
issued from the guest results in linear I/O within the .vmdk. For production VMs, one would almost always use
thick disks instead of thin disks.
Thick disk is generally lazy-zeroed, meaning that the actual data on the datastore is not erased on disk
creation. The eager-zeroed type instead fills the newly created disk with zeroes, but it also takes longer to
create.
Thin provisioned disks take almost no space at first, and only start growing when new data is written to the
disk and needs to be stored there. Empty blocks are not stored, and for this reason thin disks are also known
as sparse. This can save you a lot of space, but performance of thin disks can be noticeably slower due to
internal fragmentation. Linear guest I/O here can result in random I/O on disk/datastore. Another reason for
disks being slower is the need for them to grow, which is a bit of an overhead on the file system.
Guest OS never knows what kind of disk is used, for it the disk always looks like a regular physical disk.
One important thing about VMDK disks is that they cannot automatically shrink. You can only increase the
size of a disk, not reduce it. A related factor — when talking about Guest OS — is that every modern file
system won’t erase any data when you delete the files corresponding to that data. The data will stay on disk,
but marked as free, to be used by future files. But from the Host perspective, there is no difference, a virtual
disk is just a virtual disk with data. And if you back up a virtual disk, you will also store that data. Recent
Veeam B&R versions are able to parse NTFS volumes and skip unused blocks, and this does result in
decreased backup size, but that’s only for NTFS. In our labs, you should always use thin provisioning to save
space.
If you really must shrink a thin disk, you’ll need to zero the blocks first (e.g. with sdelete on Windows), then
either clone that disk or migrate it with Storage vMotion. Thin disk will be re-created during these operations,
and zeroes will be skipped.
You can convert a Thin disk to Thick via the Inflate operation, available in the context menu, in the Datastore
Browser. The opposite – Thick to Thin conversion — can be done, again, by Cloning or using Storage
vMotion.
Dependent vs Independent disks

Then, for the disk you create or mount you also need to pick the mode in which it will operate. This can be
changed at any time.
Dependent mode is used 95% of the time and is simply the regular mode in which disks support snapshots.
Independent persistent doesn’t support snapshots, by design. You pick this type deliberately, understanding
what this means. No snapshots mean no backups of such disk (Veeam automatically skips them), but also
that there will be no performance overhead ever. This can be useful for disks containing no important data,
but where performance is crucial, e.g. some cache data.
Independent non-persistent is a unique case. For this mode to make any sense you need to first, say, install
an OS on a disk in Dependent mode, then switch to Independent non-persistent, and from this point the disk
will have a new empty delta disk, as if that disk is running on a snapshot. New writes will go into that delta,
but the moment you reboot or shut down the VM from the host level, the delta is discarded and a new one is
created, in effect essentially rolling that disk back to the original state.
This last mode can be useful for daily testing a new build of some product that you develop, on a fresh
system. This can be done on multiple machines at once, and each will have its own separate delta, but they
will all share a single base disk. This can save a lot of space when you need a massive number of similar
VMs, such as for Remote Desktops. This mode is also used during hot-add, to prevent the mounted disk from
any changes (more on that in a future training about Backups). These disks don’t support any additional
snapshots either, and as such no image-level backups.
Networking
There are two goals that must be accomplished with networking in vSphere. One is providing the kernel
connections, directly to the host itself. These include connections from the vSphere Client to a host, from
vCenter to a host, SSH connections to hosts and connections between hosts (e.g. for purposes of High
Availability or vMotion). This is often referred to as “Management traffic”.
The other goal is providing networking connectivity for the VMs: between VMs running on the same host,
between VMs and anything else on the physical network, and also between VMs on different hosts.
The networking configuration starts with Network Adapters (Physical adapters) on a given ESXi host. Every
physical port on physical NICs of a host are automatically given names such as vmnic0, etc. Through these,
the host and its VMs will be able to communicate with the outside. These ports are connected to physical
switches, where other hosts and equipment is also connected.
Networking is then configured by using virtual switches. The basic type is known as a Standard Virtual
Switch. Virtual switches behave just like physical switches – they have ports and they send the traffic
accordingly (e.g. to a port where the target MAC address has been seen). Virtual switches are completely
done in software and are a part of the networking ESXi stack. The number of ports on a single switch is
virtually unlimited.
During the installation of ESXi you specify the TCP/IP settings, and these will be used to create the first
default virtual switch, named vSwitch0. Without this default switch, no network communication with the host
would be possible after the installation.
The right-hand side includes the Physical Adapters, and will initially have just one adapter (port) there. If there
are no adapters on the right-hand side, then whatever is on the left-hand side (VMs and host itself) won’t be
able to communicate with the physical networks. This can be used to create isolated “sandbox” environments.
You could also have multiple adapters on the right-hand side, and this allows for multipathing and link
aggregation (LACP).
The left-hand side includes VMkernel ports, these are for the host itself, and are always associated with
some IP address, and the type of traffic that will flow through this port. The basic types include: Management,
vMotion and Fault Tolerance. By using this setting you can support two networks where hosts are connected,
where one is Production, and another is used for vMotion traffic, thus isolating them from each other. The
associated IP addresses are the addresses with which the hosts are seen on the network. You can remove
and add VMkernel ports as needed.

For VMs, Virtual Machine port groups are created, and the default one is known as “VM Network”. The default
one exists so that you can easily connect VMs there, and is commonly used for regular non-isolated VMs. All
VMs in a single port group can “see” each other. When configuring a virtual NIC of a VM, you have to pick
where that NIC will be connected to, and you pick a port group, not the switch or some physical adapter. The
main feature of the VM port groups is that you can specify a VLAN ID, making the isolation of VMs on the
same network segment very convenient, e.g. VLAN 100 for Production VMs and VLAN 200 for Testing
Environment. VMs will run on the same host and in the same switch, but will never get the other group’s
traffic. Without VLANs you’d have to have separate physical and virtual switches and a lot of additional
cabling. VMs are not assigned any IP addresses here – this is their own task with static addressing, or a task
of a DHCP server on the same network.
Other virtual switch settings include:
MTU and Traffic shaping.

Promiscuous mode, which turns the switch into a hub so that it sends the traffic on all ports (can be
used for traffic capture)
MAC address changes and Forged transmits allow or disallow traffic with MAC addresses different from
what the virtual NIC is supposed to have. Generally used for security. Every virtual NIC is assigned a
MAC address, and the host knows what it is, but this can also be easily forged from within the guest
OS.
These settings are also available on the more granular level and can be overridden on every port group.
Take a look at the official Networking guide for a picture of a simple networking setup on two hosts:
https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.networking.doc/GUID-
350344DE-483A-42ED-B0E2-C811EE927D59.html (https://docs.vmware.com/en/VMware-
vSphere/6.5/com.vmware.vsphere.networking.doc/GUID-350344DE-483A-42ED-B0E2-
C811EE927D59.html)
https://docs.vmware.com/en/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-651-networking-
guide.pdf (https://docs.vmware.com/en/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-651-
networking-guide.pdf) (page 16)
A standard switch only exists within a single host, and you have to go to every host and configure its standard
switches accordingly. With many hosts and custom settings, this can become cumbersome and lead to
human errors during configuration. If you have 30 hosts in a cluster, you’ll need to change a VLAN ID 30
times. And what if you forget to set the correct VLAN ID on a given host? Its VMs will become isolated, or
potentially “see” the wrong virtual networks.
The above problem is solved with a Distributed Switch (DVS) which is created on the cluster level, and as
such requires a cluster and a vCenter.
A sample diagram of a Distributed switch is shown here:
https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.networking.doc/GUID-
B15C6A13-797E-4BCB-B9D9-5CBC5A60C3A6.html (https://docs.vmware.com/en/VMware-
vSphere/6.5/com.vmware.vsphere.networking.doc/GUID-B15C6A13-797E-4BCB-B9D9-
5CBC5A60C3A6.html)
https://docs.vmware.com/en/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-651-networking-
guide.pdf (https://docs.vmware.com/en/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-651-
networking-guide.pdf) (page 26)

First, you set up a sort of a template of the switch: create port groups and define a number of uplinks. Then,
you add ESXi hosts to the switch, and from that moment the template will be applied – and always kept
updated – on all the added hosts. Every host gets what is known as a “proxy switch” related to the whole
Distributed switch. Now for example if you update a VLAN ID, this change is propagated to all instances of
the virtual switch to all hosts. This makes it much simpler to manage, and gets rid of human errors.
Not everything is that simple though: the uplinks need to be configured at least once. Three uplinks mean that
you can assign up to 3 physical NICs to the switch, and you have to do this manually, for each host, since
only you know how it’s connected further to the physical switch(es).
VMkernel ports also need to be configured since they must have IP addresses each. You’ll have to give some
static IP (or use DHCP) to every VMkernel port on every host. With these IP addresses hosts on the switch
will communicate with each other.
A good demonstration of a Distributed Switch is the Configure > Topology view in the vSphere Web Client
(Flash version). Here you’ll see all port groups and all physical hosts with their assigned NICs cluster-wise.
Additionally, Distributed Switches have features such as Private VLANs, NetFlow, Port mirroring and many
more. The granularity here allows to customize network settings per port (compared to per port group for a
Standard switch). The latest versions of Distributed Switches even allow to filter traffic based on TCP/UPD
ports, effectively turning them into firewalls as well. Distributed Switches are used in larger companies and
are only included in the most expensive license (Enterprise Plus).
Commonly you won’t deal too much with vSphere networking, but if it proves difficult to understand or you
want to find out more, read the official docs https://docs.vmware.com/en/VMware-
vSphere/6.5/com.vmware.vsphere.networking.doc/ (https://docs.vmware.com/en/VMware-
vSphere/6.5/com.vmware.vsphere.networking.doc/)
Permissions
Permissions on vSphere allow or disallow given users to perform certain actions on certain objects.
It all starts with Roles, accessible via Administration > Roles. A role is a template of a list of permissions, and
it doesn’t specify exact objects or users, only types of objects and permissions. There are three built-in ones:
Administrator can do anything, Read-only can see objects but not modify them, and finally No access doesn’t
even see the objects. You can clone and modify them, or create new ones.
If you go to edit a role, you’ll see a tree with all existing objects types (Datastores, VMs, etc.) and actions
(Remove datastore, Create snapshot, etc.). Checkboxes define whether this action would be allowed or not.
Then, to actually apply these roles and have effective permissions, the simplest way is to use the context
menu option Assign Permissions on any object in the vSphere hierarchy. You can do this on a VM, folder,
resource pool, ESXi host or even the whole vCenter if you want. There you pick the users or groups, including
the ones from the domains, and assign them a role. By default, those permissions are also applied to all the
children objects as well, so if applied on a Resource Pool, then all VMs in that pool are also affected.
Veeam Backup and Replication also connects to vCenter or ESXi with some account, and that account must
have enough permissions to perform actions needed to backup, replicate, restore VMs, etc. One example is
that we need to have permissions to read properties of VMs and create snapshots on them – otherwise the
backup will fail. Veeam doesn’t require complete permissions, but only a portion of them, and these are listed
in the required permissions PDF doc: https://www.veeam.com/veeam_backup_9_0_permissions_pg.pdf
(https://www.veeam.com/veeam_backup_9_0_permissions_pg.pdf)

Virtual SAN (new in vSphere 5.5)

VSAN is a new way to create shared storage. Instead of having a shared SAN to which all hosts have access,
you connect multiple HDDs into the hosts, join them all together and they form a new joint distributed
datastore across the cluster. There are some minimal requirements. On every host, you’ll need to join the
HDDs into groups, and also add an SSD to that group, which will act as a cache disk for reading data. The
cluster needs to have at least three hosts. Here a VM runs on one host, but its files – most importantly disks –
will be stored on the same or other host(s). Access to those files is done via a fast network (10 Gbit dedicated
network highly recommended). Files larger than 256 GB are split into chunks and the chunks are stored
across the cluster on different hosts.
The initial v5.5 VSAN simply joins the available space of all HDDs to form the VSAN datastore (3 hosts with
10 TB each form a 30 TB VSAN datastore). To protect the data, you must use Storage Policy-based
Management (SPBM) and define a policy: how many components can fail at the same time without you
losing your data. A component is either a host or disk hosting the files.
If set to 0, this means that no protection is done. Lose the disk or host, and your data is lost.
If set to 1, VSAN will make sure to always store a synced copy of the VM files on the cluster on a
different host. In case of a single host failure, the data is preserved.
You can also set to 2, and there will be in total three instances of the VM data across the cluster.
Since this is a policy, then in case of a disaster VSAN will ensure to make another copy as quickly as
possible, provided that there’s available host or enough space to do so.
They have since then added RAID support, and all-flash VSAN (SSDs instead of HDDs).
Supposedly VSAN can be cheaper than a regular SAN, and this may be suitable for small-to-mid sized
companies. In terms of backups nothing really changes since the same VDDK/vSphere APIs are used. Only
the Direct SAN mode isn’t possible due to lack of any LUNs here.
Virtual Volumes (new in vSphere 6.0)

VVOL is a new method of working with SAN storages.
Everything discussed in the first part above about storages and datastores is the traditional approach: you
have hosts and connect them over some protocol to some storage. The host doesn’t know any characteristics
of that storage: is it made of SSDs or HDDs? what RAID type is used? and so on. In the same fashion, the
storage doesn’t have any information about what data is being stored on the LUNs, and what are the
requirements of it. There are some consumers of data that connect over iSCSI/FC/NFS, and that’s it. So, in
the traditional approach the storage administrator has to keep all of this in the head/documentation and
provision LUNs manually according to some requirements that are outside of vSphere.
With VVOL, there’s a new communications channel between a supported SAN and vCenter 6+. The storage
system is able to tell to vCenter what disks it has, of what type and how fast they are, and what RAID types
are supported (which parameters are exposed is up to the storage vendor). In turn, vCenter is able to tell the
SAN what are the requirements of the VMs. These requirements are set using SPBM policies. The SAN has
to support VVOL for all of this to work, so a firmware update may be necessary.
By using a special set of APIs called vSphere APIs for Storage Awareness (VASA), the storage system
becomes aware of the virtual volumes and their associations with the relevant virtual machines. Through
VASA, vSphere and the underlying storage system establishes a two-way out-of-band communication to

perform data services and offload certain virtual machine operations to the storage system. For example,
operations such as snapshots and clones can be offloaded.
For example, you can set up a “Platinum” policy where VMs have to be stored on SSDs only and RAID-1 –
these are your most important VMs. And, say, a “Bronze” policy enforces no RAID and HDDs. Then when you
create VMs, you select a policy to use, and vCenter together with the SAN will dynamically create LUNs for
that VM on the fitting disks.
What you see is a single large VVOL datastore, but behind the scenes a large number of small LUNs are
created and deleted as needed for the VMs, according to the policies. In fact, one LUN is created for the
configuration files, then one per every virtual disk, including the snapshots, another LUN for the swap file and
so on.
This simplifies storage management, but also hides away some lower level details and instead of simple
LUNs your storage may become a sort of a black box to you.
In terms of backups, again as with VSAN, there’s no difference except that Direct SAN is also not possible
since there are no traditional LUNs here.
Encrypted VMs
Veeam Backup & Replication provides support for encrypted VMware vSphere VMs.
Backup of encrypted VMs

(https://helpcenter.veeam.com/docs/backup/vsphere/encrypted_vms_backup.html?
ver=95u4#backup)
Replication of encrypted VMs
ver=95u4#replication)
Restore of encrypted VMs
ver=95u4#restore)
Failback of encrypted VMs
ver=95u4#failback)
Veeam Backup & Replication lets you back up encrypted VMs. The backup infrastructure must meet the
following requirements:
VM encryption instances must be preconfigured in the virtual infrastructure: you must set up the key
management server, create the VM encryption policy and assign it to VMs in advance.
The backup proxy used for backup must be working in the Virtual appliance transport mode or Network
transport mode with SSL encryption enabled.
The backup proxy working in the Virtual appliance transport mode must be deployed on an encrypted VM.
Restores can only go to Encrypted datastores, and the procedure is just reversed in such cases.
Storage Profiles
When you need to define storage requirements for a virtual machine and its virtual disks, you can create a
virtual machine storage profile. When you create the storage profile, you add storage capabilities that are
required by the applications running on the virtual machine to the profile.
During backup, Veeam Backup & Replication preserves information about the storage policy associated with
the VM, and stores this information to the backup file or replica metadata. When you restore the VM to its
original location, Veeam Backup & Replication also restores information about the VM storage policy. The
restored VM gets automatically associated with the original storage policy.
Extra info about creation of new storage profiles:
https://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.storage.doc%2FGUID-
89091D59-D844-46B2-94C2-35A3961D23E7.html (https://pubs.vmware.com/vsphere-51/index.jsp?
topic=%2Fcom.vmware.vsphere.storage.doc%2FGUID-89091D59-D844-46B2-94C2-35A3961D23E7.html)
New in vSphere 6.5

vSphere 6.5 brings:
VMFS 6 as discussed before.

Encrypted VMs, where VMDK content is completely encrypted, and if stolen cannot be recovered
without a password.
Secure boot — a UEFI related feature that prevents booting ESXi that has a tampered firmware.
Support for 6.5 was added in Veeam Backup and Replication 9.5 Update 1.
Tags: Created by Dmitriy Rozhdestvenskiy

(/bin/view/XWiki/drozhdestvenskiy) on 2017/10/05 13:38
No comments for this page

VMware Vsphere Basics

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

VMware Vsphere Basics

Загружено:

Авторское право:

Доступные форматы

6/22/2020 VMware vSphere Basics (Main.Internal Technical Docs.Official Lectures.VMware vSphere Basics.

 (/bin/view/Main/)  / Internal Support Portal (/bin/view/Main/) 

VMware vSphere Basics

During the installation, you’ll need to provide only the following:

The password for the root account.

https://xwiki.support2.veeam.local/bin/view/Main/Internal Technical Docs/Official Lectures/VMware vSphere Basics/ 3/28

https://xwiki.support2.veeam.local/bin/view/Main/Internal Technical Docs/Official Lectures/VMware vSphere Basics/ 4/28

SCSI command protocol

https://xwiki.support2.veeam.local/bin/view/Main/Internal Technical Docs/Official Lectures/VMware vSphere Basics/ 5/28

https://xwiki.support2.veeam.local/bin/view/Main/Internal Technical Docs/Official Lectures/VMware vSphere Basics/ 6/28

Things to consider when using iSCSI:

https://xwiki.support2.veeam.local/bin/view/Main/Internal Technical Docs/Official Lectures/VMware vSphere Basics/ 7/28

HP 3PAR as an example: https://i.ytimg.com/vi/pFT4-Ic7g8A/maxresdefault.jpg (https://i.ytimg.com/vi/pFT4-

https://xwiki.support2.veeam.local/bin/view/Main/Internal Technical Docs/Official Lectures/VMware vSphere Basics/ 9/28

1. Request reaches vpxd.

vSphere vs vCenter vs ESXi

https://xwiki.support2.veeam.local/bin/view/Main/Internal Technical Docs/Official Lectures/VMware vSphere Basics/ 10/28

https://xwiki.support2.veeam.local/bin/view/Main/Internal Technical Docs/Official Lectures/VMware vSphere Basics/ 11/28

Another technology considered to be part of HA is called VM Monitoring. If a guest OS hangs due to

no VM files are copied, only the CPU/memory;

Authentication and ports

https://xwiki.support2.veeam.local/bin/view/Main/Internal Technical Docs/Official Lectures/VMware vSphere Basics/ 13/28

Managed Object Browser (MOB)

https://xwiki.support2.veeam.local/bin/view/Main/Internal Technical Docs/Official Lectures/VMware vSphere Basics/ 14/28

https://xwiki.support2.veeam.local/bin/view/Main/Internal Technical Docs/Official Lectures/VMware vSphere Basics/ 15/28

https://xwiki.support2.veeam.local/bin/view/Main/Internal Technical Docs/Official Lectures/VMware vSphere Basics/ 16/28

Changed Block Tracking

https://xwiki.support2.veeam.local/bin/view/Main/Internal Technical Docs/Official Lectures/VMware vSphere Basics/ 18/28

Virtual Machine compatibility levels

https://xwiki.support2.veeam.local/bin/view/Main/Internal Technical Docs/Official Lectures/VMware vSphere Basics/ 19/28

Raw Device Mapping (RDM)

https://xwiki.support2.veeam.local/bin/view/Main/Internal Technical Docs/Official Lectures/VMware vSphere Basics/ 21/28

Disk provisioning types

Dependent vs Independent disks

but where performance is crucial, e.g. some cache data.

https://xwiki.support2.veeam.local/bin/view/Main/Internal Technical Docs/Official Lectures/VMware vSphere Basics/ 23/28

Other virtual switch settings include:

MTU and Traffic shaping.

A sample diagram of a Distributed switch is shown here:

https://xwiki.support2.veeam.local/bin/view/Main/Internal Technical Docs/Official Lectures/VMware vSphere Basics/ 24/28

https://xwiki.support2.veeam.local/bin/view/Main/Internal Technical Docs/Official Lectures/VMware vSphere Basics/ 25/28

Virtual SAN (new in vSphere 5.5)

Virtual Volumes (new in vSphere 6.0)

https://xwiki.support2.veeam.local/bin/view/Main/Internal Technical Docs/Official Lectures/VMware vSphere Basics/ 26/28

Backup of encrypted VMs

Extra info about creation of new storage profiles:

New in vSphere 6.5

VMFS 6 as discussed before.

Tags: Created by Dmitriy Rozhdestvenskiy

No comments for this page

https://xwiki.support2.veeam.local/bin/view/Main/Internal Technical Docs/Official Lectures/VMware vSphere Basics/ 28/28

Вам также может понравиться