What is the difference in Vsphere 5.5,6.0 and 6.5?

VMware Platform
Services Controller
(PSC)
•
•
•

Mware Platform Services Controller (PSC) is a new

service in vSphere 6 that handles the infrastructure
security functions such as vCenter Single Sign-On,
licensing, certificate management and server reservation.

PSC provides one appliance- or Windows-based virtual

machine platform to systems administrators for centralized
management of these common infrastructure services.

PSC is a distributed service that

automatically replicates information such as licenses,
permissions and roles to other PSC instances. The
maximum number of PSCs per vSphere domain is set at
eight. High-availability for PSCs is achieved through
local load-balancing technologies, though only four PSCs
can reside behind a load balancer. PSCs are also latency
sensitive and can only tolerate up to five minutes of time
skew between PSC nodes.

In vSphere 6, the following components are installed in

PSC:

• VMware Appliance Management Service (only in

appliance-based PSC)

• VMware License Service

• VMware Component Manager

• VMware Identity Management Service

• VMware HTTP Reverse Proxy

• VMware Service Control Agent

• VMware Security Token Service

• VMware Common Logging Service

• VMware Syslog Health Service

• VMware Authentication Framework

• VMware Certificate Service

• VMware Directory Service

• In vSphere 6.0 they separated vCenter into two separate

pieces: vCenter and PSC. PSC handles things that you
might want for multiple vCenter servers, like there is a
good chance with authentication, license management,
and SSL certificate management, if you had multiple
vCenter servers, those roles will probably be the same for
both vCenter servers, so instead of managing two or more,
you only manage it in one place in the PSC. Everything
that's not in the PSC is in vCenter, like inventory, logging,
and so on. For most SMB size environments a single
vCenter (VCSA) with embedded PSC will be more than
sufficient to handle everything.

vCenter Server and Platform

Services Controller Deployment
Types
Last Updated 09/05/2018 6
Add To MyLibrary
< Ask New Question

You can deploy the vCenter Server Appliance or install vCenter Server for
Windows with an embedded or external Platform Services Controller. You
can also deploy a Platform Services Controller as an appliance or install it
on Windows. If necessary, you can use a mixed operating systems
environment.

Before you deploy the vCenter Server Appliance or install vCenter

Server for Windows, you must determine the deployment model that is
suitable for your environment. For each deployment or installation, you
must select one of the three deployment types.
 vCenter Server and Platform Services Controller Deployment Types
Deployment Type Description
vCenter Server with an All services that are bundled with the Platform Services Controller are deployed together with
embedded Platform Services
the vCenter Server services on the same virtual machine or physical server.
Controller
Platform Services Controlle
Only the services that are bundled with the Platform Services Controller are deployed on the
virtual machine or physical server.
vCenter Server with an Only the vCenter Server services are deployed on the virtual machine or physical server.
external Platform Services
You must register such a vCenter Server instance with a Platform Services Controller instance
Controller that you previously deployed or installed.
(Requires external Platform
Services Controller)

vCenter Server with an Embedded Platform Services Controller

Using an embedded Platform Services Controller results in a standalone

deployment that has its own vCenter Single Sign-On domain with a single
site.

Starting with vSphere 6.5 Update 2, other instances of vCenter Server with
an embedded Platform Services Controller can be joined to enable
enhanced linked mode.

vCenter Server with an Embedded Platform Services Controller

vCenter Server with an Embedded Platform Services Controller

nstalling vCenter Server with an embedded Platform Services

Controller has the following advantages:

• The connection between vCenter Server and the Platform

Services Controller is not over the network, and vCenter
Server is not prone to outages caused by connectivity and name
resolution issues between vCenter Server and the Platform
Services Controller.
• If you install vCenter Server on Windows virtual machines or
physical servers, you need fewer Windows licenses.
• You manage fewer virtual machines or physical servers.
You can configure the vCenter Server Appliance with an
embedded Platform Services Controller in vCenter High Availability
configuration. For information, see vSphere Availability.

Note:

After you deploy or install vCenter Server with an embedded Platform

Services Controller, you can reconfigure the deployment type and switch
to vCenter Server with an external Platform Services Controller.

Platform Services Controller and vCenter Server with an

External Platform Services Controller
When you deploy or install a Platform Services Controller instance, you
can create a vCenter Single Sign-On domain or join an existing vCenter
Single Sign-On domain. Joined Platform Services Controller instances
replicate their infrastructure data, such as authentication and licensing
information, and can span multiple vCenter Single Sign-On sites. For
information, see Understanding vSphere Domains, Domain Names, and
Sites.

You can register multiple vCenter Server instances with one common
external Platform Services Controller instance. The vCenter
Server instances assume the vCenter Single Sign-On site of the Platform
Services Controller instance with which they are registered. All vCenter
Server instances that are registered with one common or different
joined Platform Services Controller instances are connected in Enhanced
Linked Mode.

Example of Two vCenter Server Instances with a Common

External Platform Services Controller

Installing vCenter Server with an external Platform Services

Controller has the following disadvantages:
 • The connection between vCenter Server and Platform Services
Controller might have connectivity and name resolution issues.
• If you install vCenter Server on Windows virtual machines or
physical servers, you need more Microsoft Windows licenses.
• You must manage more virtual machines or physical servers.

For information about the Platform Services Controller and vCenter

Server maximums, see the Configuration Maximums documentation.

For information about configuring the vCenter Server Appliance with an

external Platform Services Controller in vCenter High Availability
configuration, see vSphere Availability.

Mixed Operating Systems Environment

A vCenter Server instance installed on Windows can be registered with
either a Platform Services Controller installed on Windows or a Platform
Services Controller appliance. A vCenter Server Appliance can be
registered with either a Platform Services Controller installed on
Windows or a Platform Services Controller appliance. Both vCenter
Server and the vCenter Server Appliance can be registered with the
same Platform Services Controller.

Example of a Mixed Operating Systems Environment with an External

Platform Services Controller on Windows

Example of a Mixed Operating Systems Environment with an External

Platform Services Controller Appliance
Note:

To ensure easy manageability and maintenance, use only appliances or

only Windows installations of vCenter Server and Platform Services
Controller.

Using vCenter Server in Linked Mode

You can join multiple vCenter Server systems using vCenter Linked Mode to allow them
to share information. When a server is connected to other vCenter Server systems
using Linked Mode, you can connect to that vCenter Server system and view and
manage the inventories of all the vCenter Server systems that are linked.

Linked Mode uses Microsoft Active Directory Application Mode (ADAM) to store and
synchronize data across multiple vCenter Server systems. ADAM is installed
automatically as part of vCenter Server installation. Each ADAM instance stores data
from all of the vCenter Server systems in the group, including information about roles
and licenses. This information is regularly replicated across all of the ADAM instances in
the connected group to keep them in sync.

When vCenter Server systems are connected in Linked Mode, you can:

■ Log in simultaneously to all vCenter Server systems for which you have valid credentials.
■ Search the inventories of all the vCenter Server systems in the group.
■ View the inventories off all of the vCenter Server systems in the group in a single inventory view.

You cannot migrate hosts or virtual machines between vCenter Server systems
connected in Linked Mode.

For additional information on troubleshooting Linked Mode groups, see ESX and
vCenter Server Installation Guide.
Esxtop is a command-line tool that gives administrators
real-time information about resource usage in a vSphere
environment.

With esxtop, an administrator can monitor CPU, disk

space, memory and network resource usage. The
command can be run either directly at the console or
remotely, by using a secure shell console.

Esxtop can be run in three modes -- interactive (real time),

batch (save to file) and replay (from vm-support).
Information is displayed in a spreadsheet-like format. The
amount of raw data generated by the esxtop command --
including CPU percentages over time and number of items
in a resource pool -- also makes it a powerful tool for
troubleshooting ESX server performance.

Esxtop is essentially a VMware version of top,

the Linux command line that displays real-
time CPU information. The tool runs in the Linux-based
Service Console, which means it only supports VMware
ESX hosts. For ESXi hosts, VMware offers a tool called
resxstop.

VMware vCenter Server Virtual

Appliance (vCSA) features
and benefits.
The VMware vCenter Server Virtual Appliance (vCSA) provides an alternative option for

organizations that chose not to run the Windows vCenter Server but still require centralised

management of VMware vSphere deployments in the enterprise.

It provides exactly the same functionality as the traditional Windows vCenter Server but

packaged in a Linux distribution. I know that some of my pure UNIX and LINUX customers

have been asking for this for a while.

It’s been available as a technology preview since 2009 as “vCenter 2.5 on Linux” but has finally

arrived with vSphere 5 to give customers’ an alternative to the Windows vCenter Server. Expect

to see it available for download when vSphere 5 goes GA.

Update Manager.

Update Manager enables centralized, automated patch and version

management for VMware vSphere and offers support for
VMware ESXi hosts, virtual machines, and virtual appliances.

With Update Manager, you can perform the following tasks:

• Upgrade and patch ESXi hosts.

• Install and update third-party software on hosts.
• Upgrade virtual machine hardware, VMware Tools, and virtual
appliances.

Update Manager requires network connectivity with VMware vCenter

Server. Each installation of Update Manager must be associated
(registered) with a single vCenter Server instance.

The Update Manager module consists of a server component and of a

client component.

You can use Update Manager with either vCenter Server that runs on
Windows or with the vCenter Server Appliance.

If you want to use Update Manager with vCenter Server, you have to
perform Update Manager installation on a Windows machine. You can
install the Update Manager server component either on the same Windows
server where the vCenter Server is installed or on a separate machine. To
install Update Manager, you must have Windows administrator credentials
for the computer on which you install Update Manager.

If your vCenter Server system is connected to other vCenter

Server systems by a common vCenter Single Sign-On domain, and you
want to use Update Manager for each vCenter Server system, you must
install and register Update Manager instances with each vCenter
Server system. You can use an Update Manager instance only with
the vCenter Server system with which it is registered.

The vCenter Server Appliance delivers Update Manager as an optional

service. Update Manager is bundled in the vCenter Server Appliance.

In vSphere 6.5, it is no longer supported to register Update Manager to

a vCenter Server Appliance during installation of the Update
Managerserver on a Windows machine.

The Update Manager client component is a plug-in that runs on

the vSphere Web Client. The Update Manager client component is
automatically enabled after installation of the Update Manager server
component on Windows, and after deployment of the vCenter Server
Appliance.

You can deploy Update Manager in a secured network without Internet

access. In such a case, you can use the
VMware vSphere Update Manager Download Service (UMDS) to download
update metadata and update binaries.

Purple Screen of Death

(PSOD)
A Purple Screen of Death (PSOD) is a diagnostic screen
with white type on a purple background that is displayed
when the VMkernel of an ESX/ESXi host experiences a
critical error, becomes inoperative and terminates
any virtual machines that are running.

Typically, the PSOD details the memory state at the time

of the crash and includes other information such as the
ESX/ESXI version and build, the exception type, register
dump, what was running on each CPU at the time of the
crash, backtrace, server uptime, error messages and core
dump information.
The core dump (or memory dump) is a file that contains
further diagnostic information from a PSOD that can be
given to VMware support to determine a root cause
analysis for the failure.

The term Purple Screen of Death is a play on the Blue

Screen of Death, the informal name given by users to the
Windows general protection fault (GPF) error.

This was last updated in September 2013

How To Deal With PSOD - The

Purple Screen of Death
14.6.2018 13:02

Contents
What is it?
Why does it happen?
What's the impact?
What to do when it happens?
How to prevent it?

What is it?
PSOD stands for Purple Screen of Diagnostics, often referred to
as Purple Screen of Death: from the more known Blue Screen of
Death encountered on Microsoft Windows.

It’s a diagnostic screen displayed by VMware ESXi when the

kernel detects a fatal error in which it either is unable to safely
recover from, or cannot continue to run without having a much
higher risk of a major data loss.

It shows the memory state at the time of the crash and also
additional details which are important in troubleshooting the cause
of the crash: ESXi version and build, exception type, register
dump, backtrace, server uptime, error messages and information
about the core dump(a file generated after the the error, containing
further diagnostic information).
This screen is visible on the console of the server. In order to see
it, you will need to either be in the datacenter and connect a
monitor or remotely using the server’s out-of-band management
(iLO, iDRAC, IMM… depending on your vendor).

DID YOU KNOW?

The screen is referred to as
either Purple or Pink , but in fact the
color is Dark Magenta (RGB:171,0,171
| CMYK:0.00, 1.00, 0.00, 0.33)
Why does it happen?
The PSOD is a kernel panic. Even though we all know that ESXi is
not based on UNIX, the panic implementation fits the UNIX
definition. The ESXi kernel (vmkernel) triggers this safety measure
in response to an event/error which is unrecoverable and would
mean that continuing to run would pose a high risk for the services
and VMs. To put it simply: when the ESXi hosts feels it became
corrupted, it commits “seppuku” and, while bleeding its purple
blood, writes a suicide letter detailing why it did it!

The most common causes for a PSOD are:

1. Hardware failures, mostly RAM or CPU related. They normally
throw out a “MCE” or “NMI” error.

• “MCE” - Machine Check Exception, which is a mechanism

within the CPU to detect and report hardware issues. There
are important details for identifying the root cause of the
issue in the codes displayed on the purple screen.
• “NMI” - non-maskable interrupt, which is a hardware
interrupt that cannot be ignored by the processor. Since
NMI is a very important message about a HW failure, the
default response starting with ESXi 5.0 and later is to
trigger a PSOD. Earlier versions were just logging the error
and continuing. Same as with MCEs, purple screen caused
by NMI will provide important codes that are crucial for
troubleshooting.

2. Software bugs

• improper interactions between ESXi SW components

(ex: KB2105711)
• race conditions (ex: KB2136430)
• out of resources: memory, heap, buffer
(ex: KB2034111, KB2150280)
• infinite loop + stack overflow(ex: KB2105522)
• improper or unsupported configuration parameters
(ex: KB2012125, KB2127997)

3. Misbehaving drivers; bugs in drivers that try to access some

incorrect index or non-existing method
(ex: KB2146526 , KB2148123)

DID YOU KNOW?

You can even trigger manually a PSOD
for testing purposes or if you are just
curious to see it happen.
Log in to the ESXi host via DCUI or SSH
with a privileged account and run:
vsish -e set /reliability/crashMe/Panic

Obviously a test system is recommended,

ideally a virtual nested ESXi so you can
easily observe the console. Also make
sure you finish reading this article to
understand the implications of this action
and the effect on your test system.

What’s the impact?

When the panic occurs and the host crashes, it terminates all the
services running on it together with all the virtual
machines hosted. The VMs are not gracefully shutdown, but
rather abruptly powered off. If the host is part of a cluster and
you’ve configured HA, these VMs will be started on the other hosts
in the cluster. Besides the outage and the unavailability of the VMs
during the time they are down, some critical applications like
database servers, message queues or backup jobs may be
affected by the “dirty” shutdown.

Additionally, all other services provided by the host will be

terminated, so if your host is a member of a VSAN cluster, a
PSOD will impact vSAN as well.

For me, the most troublesome aspect of a PSOD is that it makes

you lose trust in your infrastructure and the anxiety it creates, at
least until you get to the bottom of it. Ok, you can recover by
rebooting and may have HA or even FT so the impact may not be
devastating… but until you don’t solve the root cause, the thought
that this can happen again or on an another server can keep you
up at night.

What to do when it happens?

1. Analyze the purple screen message
One of the most important things to do when you have a PSOD is
to take a screenshot. If you are connecting remotely(IMM, iLO,
iDRAC,...) to the console it will be easy taking a screenshot, but if
you have to go to the datacenter, you may need to literally take out
your phone and snap a picture of the screen. There’s a lot of
useful information about the cause of the crash in that screen.
2. Contact VMware support
Before you start further investigation and troubleshooting it is
advisable to contact VMware support, if you have a support
contract. In parallel with your investigation they will be able to
assist you in making the Root Cause Analysis (RCA).

3. Reboot the affected ESXi host

In order to recover the server you will need to reboot it. I would
also advise keeping it in maintenance mode until you perform the
full RCA, identify the cause and fix it. If you can’t afford keeping it
in maintenance mode, at least fine tune your DRS rules so that
only un-important VMs will run on it, so that if another PSOD hits
the impact will be minimal.

4. Get the core dump

After the server boots up you should collect the coredump. The
coredump, also called vmkernel-zdump is a file containing logs
with similar, but more detailed information to that seen on the
purple diagnostic screen and will be used in further
troubleshooting. Even if the cause of the crash might seem
obvious from the PSOD message that you analyzed in step 1, it is
advisable to confirm it by looking at the logs from the coredump.

Depending on your configuration you may have the core dump in

one of these forms:

a. On the scratch partition

b. As a .dump file on one of the host’s datastores
c. As a .dump file on the vCenter - through the netdump service

The coredump becomes especially important if the configuration of

the host is to automatically reset after a PSOD, in which case you
will not get to see the message on screen.

You can copy the dumpfile out of the ESXi host using SCP and
then open it using a text editor (like Notepad++). This will contain
the contents of the memory at the time of the crash and the first
parts of it contain the messages you saw on the purple screen.
The whole file may be requested by VMware support, but you can
only extract the vmkernel log, which is a bit more … digestible:
5. Decipher the error

Troubleshooting and Root Cause Analysis can make one feel like
Sherlock Holmes. PSODs can sometimes turn into a Arthur Conan
Doyle inspired story, but in most cases it’s a pretty straightforward
process where it will be hard to get to the fifth “why” of the 5 Whys
technique.

The most important symptom, and the one you should start with, is
the error message generated by the purple screen. Luckily, the
number of error messages that can be produced is finite:

Exception Type 0 #DE: Divide Error

Exception Type 1 #DB: Debug Exception
Exception Type 2 NMI: Non-Maskable Interrupt
Exception Type 3 #BP: Breakpoint Exception
Exception Type 4 #OF: Overflow (INTO instruction)
Exception Type 5 #BR: Bounds check (BOUND instruction)
Exception Type 6 #UD: Invalid Opcode
Exception Type 7 #NM: Coprocessor not available
Exception Type 8 #DF: Double Fault
Exception Type 10 #TS: Invalid TSS
Exception Type 11 #NP: Segment Not Present
Exception Type 12 #SS: Stack Segment Fault
Exception Type 13 #GP: General Protection Fault
Exception Type 14 #PF: Page Fault
Exception Type 16 #MF: Coprocessor error
Exception Type 17 #AC: Alignment Check
Exception Type 18 #MC: Machine Check Exception
Exception Type 19 #XF: SIMD Floating-Point Exception
Exception Type 20-31: Reserved
Exception Type 32-255: User-defined (clock scheduler)

Since the kernel panic is handled by the CPU, for more

information about these Exceptions see Intel 64 and IA-32
Architectures Software Developer’s Manual, Volume 1: Basic
Architecture and Intel 64 and IA-32 Architectures Software
Developer’s Manual, Volume 3A.

The most common cases are covered in separate VMware KB

articles and I will just maintain a reference table of such errors
here since the articles are very detailed and well documented. So
use this table as an index for the PSOD errors:

Example Error Detailed KB Article

LINT1/NMI (motherboard nonmaskable Using hardware NMI
interrupt), undiagnosed facilities to troubleshoot
Panic requested by one or more 3rd unresponsive hosts
party NMI handlers (1014767)
Understanding an "Oops"
COS Error: Oops purple diagnostic screen
(1006802)
Understanding a "Lost
Heartbeat" purple
Lost Heartbeat
diagnostic screen
(1009525)
Understanding ASSERT
ASSERT and NOT_IMPLEMENTED
bora/vmkernel/main/pframe_int.h:527 purple diagnostic screens
(1019956)
Understanding ASSERT
NOT_IMPLEMENTED
and NOT_IMPLEMENTED
/build/mts/release/bora-
84374/bora/vmkernel/main/util.c:83 purple diagnostic screens
(1019956)
Spin count exceeded (iplLock) - Understanding a "Spin
possible deadlock count exceeded" purple

PCPU 1 locked up. Failed to ack TLB
invalidate
#GP Exception(13) in world
4130:helper13-0 @ 0x41803399e303
#PF Exception type 14 in world
136:helper0-0 @ 0x4a8e6e
Machine Check Exception: Unable to
continueHardware (Machine) Error
Hardware (Machine) Error
PCPU: 1 hardware errors seen since
boot (1 corrected by hardware)
diagnostic screen
(1020105)
Understanding a Failed to
ack TLB invalidate purple
diagnostic screen
(1020214)
Understanding Exception
13 and Exception 14
purple diagnostic screen
events (1020181)
Decoding Machine Check
Exception (MCE) output
after a purple screen error
(1005184)

6. Check logs

It may happen that the cause is not very obvious from looking at
the purple screen message or at the core dump log, so the next
place where to look for clues is in the host logs, especially at the
time interval just preceding the PSOD. Even when you feel you
have located the cause, it’s still advisable to avoid being
parsimonious and confirm it by looking at the logs.

If you are administering an enterprise environment it’s likely you

have some specialized log management solution at hand
(like VMware Log Insight or SolarWinds LEM) so it will be easy to
browse through those logs, but if you don’t have a log
management you can easily export them.

The most interesting log files to explore would be:

Components Location What is it

Contains all general log
System /var/log/syslog.log messages and can be used
messages
for troubleshooting.
Records activities related
to virtual machines and
VMkernel /var/log/vmkernel.log ESXi. Most PSOD relevant
entries will be in this log, so
pay special attention to it.
Contains information about
ESXi host /var/log/hostd.log the agent that manages
agent log
and configures the ESXi
 host and its virtual
machines.
Records activities related
to virtual machines. Watch
VMkernel
/var/log/vmkwarning.log for heap exhaustion(Heap
warnings
WorkHeap) related log
entries.
Contains information about
the agent that
communicates with
vCenter agent
/var/log/vpxa.log vCenter, so you can use it
log
to spot tasks triggered by
the vCenter and might
have caused the PSOD.
Contains a record of all
commands typed, so you
Shell log /var/log/shell.log
can correlate the PSOD to
a command executed.

How to prevent it?

Most of the software related PSODs are resolved by patches, so
make sure you are up to date with the latest versions.

Make sure that your servers are on VMware’s Hardware

Compatibility Checklist, together with all the devices and adapters.
This will protect from some of the unexpected hardware related
issues, but it will also ensure that VMware support will be able to
support you in case of a PSOD.

As described above in “Why it happens”, misbehaving drivers are

also an often cause of PSODs, so it’s imperative to regularly check
vendors’ support websites for updated firmware and drivers and
especially for the documented PSOD causing drivers to respond
as soon as possible by upgrading them.

At Runecast, we regularly analyze the entire VMware Knowledge

Base (kb.vmware.com) which consists of more than 30,000
articles. We are extracting actionable insights from the KBs in
order to proactively make virtualized infrastructures more resilient,
secure and efficient. We are very familiar with the PSOD and are
able to identify most of the preconditions that can lead to this
problem. By proactively analyzing your environment, Runecast
Analyzer will help you steer away from these issues, so you can
have the peace of mind that most PSODs lurking in your
environment are prevented.
What ports are required for p2v?

Have a question on ports required to P2V a server to vCenter server

cluster (not directly to ESXi host) with the standalone converter tool
installed directly on the source.

Do I need to open the firewall ports from source to vCenter cluster IP or to

the individual vCenter servers and to all ESXi hosts in the HA cluster as
well ?

Source machine with Standalone Converter Installed ==>> Destination

vCenter Server Cluster

from Source machine TCP 443 undirectional to vCenter cluster IP for

vCenter communications.....and to individual vCenter servers in the
vcenter cluster and all ESXi hosts??
from source machine TCP 902 unidirectional to vCenter server cluster IP
for cloning process.....and to individual vCenter servers in the vcenter
cluster and all ESXi hosts??

Thank you for your help in advance!!!

RM – Array Based Replication vs.

vSphere Replication
GS Khalsa posted April 8, 2015

18 Comments

inShare
UPDATE: a new article has been published that supersedes this one. If
you have reached this page through a search or bookmark, then read the
following article instead:

SRM – Array Based Replication vs. vSphere

Replication (new version)
SRM supports two different replication technologies, Storage Array or
Array-Based Replication and vSphere Replication. One of the key
decisions when implementing SRM is which technology to use and for
what VMs. The two technologies can be used together in an SRM
environment though not to protect the same VM. Given that, what are
the differences and why would you use one over the other? This table
will provide all the answers you need:
Array-Based Replication vSphere Replication
Type Replication using the storage Replication using the
layer host/vSphere layer
RPO min/max 0 up to max supported by 15 mins to 24 hours
vendor
Scale Scales up to 5,000 VMs Scales up to 2,000 VMs
protected/2,000 simultaneously (protected & recoverable) per
recoverable per vCenter/SRM vCenter/SRM pair
pair
Write order fidelity Supports write order fidelity Supports write order fidelity
within and across multiple on the disks/VMDKs that
VMs in the same consistency make up a VM, consistency
group cannot be guaranteed across
multiple VMs
Replication level Replicates at the LUN/VMFS Replicates at the VM level
or NFS volume level
Replication configuration Replication is configured and Replication is configured and
managed on the storage array managed in the vSphere Web
Client
Array/ vendor types Requires same storage Can support any storage
replication solution at both solution at either end including
 sites (eg. EMC RecoverPoint, local storage as long as it is
NetApp vFiler, IBM SVC, etc) covered by the vSphere HCL
Storage supported Replication supported on FC, Supports replicating VMs on
iSCSI or NFS storage only local, attached, VSAN, FC,
iSCSI or NFS storage
Cost Replication and snapshot vSphere Replication is
licensing is required included in vSphere Essentials
Plus 5.1 and higher
Deployment Deployment is fairly involved Deployment requirements are
and must include storage minimal. OVF at each site and
administration and possibly start configuring replications
networking
Application consistency Depending on the array, Supports VSS & Linux file
application consistency may be system application consistency
supported with the addition of
agents to the VM
FT VMs Can replicate UP FT protected Cannot replicate FT protected
VMs (once recovered VM is VMs
no longer FT enabled). Does
not support SMP FT VMs.
Powered off Able to replicate powered off Can only replicate powered on
VMs/Templates/Linked VMs, Templates, Linked VMs. Cannot replicate
clones/ISO’s Clones (as long as all nodes in powered off VMs, Templates,
the snapshot tree are replicated Linked Clones, ISOs or any
as well) and ISOs non-VM files
RDM support Physical and Virtual mode Only Virtual mode RDMs can
RDMs can be replicated be replicated
MSCS support VMs that are part of a MSCS Cannot replicate VMs that are
cluster can be replicated part of a MSCS cluster. VR
cannot replicate disks in multi-
writer mode.
vApp support Replicating vApps is supported Replicating vApps is not
possible. However, it is
possible to replicate VMs that
are part of a vApp and to
create a vApp at the recovery
site that they are recovered into
vSphere versions supported Hosts running vSphere 3.5-6.0 Hosts must be running vSphere
are supported 5.0 or higher
MPIT Multiple point in time Supports up to 24 recovery
snapshots or rollback is points
supported by some supported
array vendors (eg. EMC
RecoverPoint)
Snapshots Supports replicating VMs with Supports replicating VMs with
snapshots and maintaining the snapshots however the tree is
 snapshot tree collapsed at the target site
Response to Host failure Replication is not impacted Host Failure, and the VM
restarting on another host
triggers a full sync. For details
about what a full sync involves
see the vSphere Replication
FAQ
If you want more information on supported array-based replication
vendors and compatibility check out the VMware Compatibility Guide.
The vendor for the array you have or are interested in is also a great
source for information. Reading the release notes for your SRA is highly
recommended

VMkernel:-
VMkernel:- VMkernel is the core operating
operating system which
provides means for running different processes
processes on
the system, including management applications and
agents as well as virtual machines. It also has control of
all the hardware devices on the server, and manages
resources for the applications.

What are the processes runs on VMkernel:-

VMkernel:-
DCUI, VMM, CIM, Different agents like HA agents

DCUI-
DCUI- Direct Console User Interface- It is a BIOS like
menu driven Esxi host configuration and management
interface which is accessible through the console of the
Esxi host. It is mainly used for initial Host
configuration.

The virtual machine monitor (VMM)-

(VMM It is
the process that provides the execution environment for
a virtual machine, as well as a helper process known
as VMX.
VMX

The Common Information Model (CIM) system:-

system CIM is
theinterface
interface that enables hardware-
hardware-level management and
monitoringfrom
monitoring remote applications via a set of
standard APIs.

What are user world processes-

processes-
The term “user world” refers to a set of process
running above the VMkernel operating system.
This process are (i) HOSTD (ii) VPXA (ii) VMware
HA Agents (iv) SYSLOG deamon (v) NTP and SNMP

• HOSTD:-
HOSTD It is the process that authenticates users
and keeps track of which users and groups have which
privileges. It also allows you to create and manage local
users. The HOSTD process provides a programmatic
interface to VMkernel and is used by direct VI Client
connections as well as the VI API.

• VPXA:-
VPXA:-The vpxa process is the agent used to connect
to VirtualCenter server. It runs as a special system user
calledvpxuser. It acts as the intermediary between
the hostd agent and VCenter server.

What is the difference between VPXA, VPXD,

HOSTD?
HOSTD?
Hostd is demon or service runs in every ESXi host and
performs major tasks like, VM power on, local user
management etc. But when ESXi host joins in a
vCenter server Vpxa agent gets activated and talk to
Vpxd service which runs in vCenter server. So the
conclusion is Vpxd talks to Vpxa and Vpxa talks to
hostd, this is how Vpxd (vCenter demon) talks to
hostd demon via Vpxa agents.
 What initial tasks can be done by DCUI-
DCUI-
• Set administrative password
• Configure networking
• Perform simple network tests
• View logs
• Restart agents
• Restore defaults

Describe VMware System Image Design-

Design-
The ESXi system has two independent banks of
memory, each of which stores a full system image, as a
fail-safe for applying updates. When you upgrade the
system, the new version is loaded into the inactive bank
of memory, and the system is set to use the updated
bank when it reboots. If any problem is detected during
the boot process, the system automatically boots from
the previously used bank of memory. You can also
intervene manually at boot time to choose which image
to use for that boot, so you can back out of an update
if necessary.
At any given time, there are typically two versions of
VI Client and two versions of VMware Tools in the
store partition.

ESXi Log File Locations

Last Updated 08/12/2015 3
Add To MyLibrary
< Ask New Question

ESXi records host activity in log files, using a syslog facility.

Compone
Location Purpose
nt
VMkernel /var/log/vmkernel.log Records
activities
related to
virtual
machines
and ESXi.
VMkernel /var/log/vmkwarning.log Records
warnings activities
related to
virtual
machines.
VMkernel /var/log/vmksummary.log Used to
summary determine
uptime and
availability
statistics
for ESXi (co
mma
separated).
ESXi host /var/log/hostd.log Contains
agent log information
about the
agent that
manages and
Compone
Location Purpose
nt
configures
the ESXi host
and its virtual
machines.
vCenter /var/log/vpxa.log Contains
agent log information
about the
agent that
communicate
s with
vCenter
Server (if the
host is
managed by
vCenter
Server).
Shell log /var/log/shell.log Contains a
record of all
commands
typed into
the ESXi
Shell as well
as shell
events (for
example,
when the
shell was
enabled).
Authenticat /var/log/auth.log Contains all
ion events related
to
authenticatio
n for the local
system.
System /var/log/syslog.log Contains all
messages general log
messages and
can be used
for
troubleshooti
ng. This
information
Compone
Location Purpose
nt
was formerly
located in the
messages log
file.
Virtual The same directory as the affected virtual Contains
machines machine's configuration files, named virtual
vmware.log and vmware*.log. For machine
example, /vmfs/volumes/datastore power events,
/virtual machine/vwmare.log system
failure
information,
tools status
and activity,
time sync,
virtual
hardware
changes,
vMotion
migrations,
machine
clones, and
so on.