Making LUN Decisions for VMFS datastore

A proper planning is required to set up storage for ESXi system before formatting the LUNs with VMFS datastores. Keep in mind the following considerations when deciding the LUN:

• Each LUN must contain only one VMFS datastore
• If multiple VMs access the same VMFS, use disk shares to prioritize VMs.
• Each LUN should have the correct RAID level and storage characteristic for the applications running in VMs that use the LUN.

Large LUNs can be preferred for the following regions:

• Fewer VMFS datastores to manage.
• More flexible for resizing virtual disks, doing snapshots, and so on.
• More flexible to create more VMs

Smaller LUNs can be preferred for the following region:

• Less wasted storage space.
• Different applications might need different RAID characteristics.
• More flexible as multipathing policy and disk shares are set per LUN.
• Use of Microsoft Cluster Service requires that each cluster disk resource is in its own LUN.
• Better performance because there is less contention for a single volume.

It’s not a simple method to determine the number and size of LUNs to provision, when the storage characterization for a VM is not available. You should experiment using a Predictive or Adaptive scheme.

Predictive Scheme is that where you provision several small LUNs with different storage characteristics and then you create a VMFS datastore on each LUN. Create virtual disks on appropriate (RAID) VMFS datastore according to application recommendation.

Adaptive Scheme is that when you provision less Large LUNs (RAID 1+0 or RAID 5), with write caching enabled, create VMFS datastore on that LUN, create multiple virtual disks on the VMFS datastore, run your applications if performance is acceptable you can use this scheme.

Thanks to VMware, Information is from the white paper provided by VMware.

Read More

SplitRX mode

SplitRx mode, a new feature in ESXi 5.0, uses multiple physical CPUs to process network packets received in a single network queue. This feature can significantly improve network performance for certain workloads.

Workloads like: ?

• Multiple virtual machines on one ESXi host all receiving multicast traffic from the same source. (SplitRx mode will typically improve throughput and CPU efficiency for these workloads.) ?
• Traffic via the vNetwork Appliance (DVFilter) API between two virtual machines on the same ESXi host. (SplitRx mode will typically improve throughput and maximum packet rates for these workloads.)

This feature, which is supported only for VMXNET3 virtual network adapters, is individually configured for each virtual NIC using the ethernetX.emuRxMode variable in each virtual machine’s .vmx file (where X is replaced with the network adapter’s ID).

The possible values for this variable are: ? ethernetX.emuRxMode = “0″
This value disables splitRx mode for ethernetX. ?

ethernetX.emuRxMode = “1″
This value enables splitRx mode for ethernetX.

To change this variable through the vSphere Client:

1 Select the virtual machine you wish to change, then click Edit virtual machine settings.
2 Under the Options tab, select General, then click Configuration Parameters.
3 Look for ethernetX.emuRxMode (where X is the number of the desired NIC). If the variable isn’t present, click Add Row and enter it as a new variable.
4 Click on the value to be changed and configure it as you wish. The change will not take effect until the virtual machine has been restarted.

Thanks to VMware, Information is from the white paper provided by VMware.

Read More

DRS Automation Threshold

The migration threshold specifies the tolerance of imbalance of the Current Host Load Standard Deviation relating to the Target Host Load Standard Deviation. DRS assign a priority level to a recommendation and compared to the migration threshold. If the priority level is less than or equal to the migration threshold, the recommendation is displayed or applied.

Level 1 (Conservative)

When Selecting this level, only mandatory moves, priority-one recommendations are executed. Mandatory moves are issued when:

• The ESXi host enters maintenance mode, Host enters standby mode, An affinity or anti-affinity rule is violated, The sum of the reservations of the VMs exceeds the capacity of the host

Level 2 (moderately conservative)

The level 2-migration threshold only applies priority-one and priority-two recommendations, priority two recommendations promise a very good improvement in the cluster’s load balance.

Level 3 (moderate)

The level 3-migration threshold is the default migration threshold when creating DRS clusters. The moderate migration threshold applies priority-one, two and three recommendations, promising a good improvement in the cluster’s load balance.

Level 4 (moderately aggressive)

The level 4-migration threshold applies all recommendations up to priority level four. Priority-four recommendations promise a moderate improvement in the cluster’s load balance.

Level 5 (aggressive)

The level 5 migration threshold is the right-most setting on the migration threshold slider and applies all five priority level recommendations; every recommendation which promises even a slight improvement in the cluster’s load balance is applied.

VMware DRS assigns integer priority ratings to the migration recommendations it makes. You can better understand the meaning of a priority rating if you are aware of the algorithm that calculates it.

Source this information is VMware vSphere 5 Clustering technical deepdive from Frank Denneman and Duncan Epping, Thanks to them and VMware.

Read More

What’s in vCenter Database

The vCenter database mainly consists of alarm/event data, HA/DRS data, ESX host information, task/scheduled tasks and VM information. All ESXi server and VM configuration data is stored on each ESXi server and is simply read and displayed by vCenter. You can also use the vSphere Client to connect directly to the ESXi servers without vCenter and modify the same configuration data. Once you add the ESXi host back into vCenter it reads all the configuration info from that host. The database is not critical to the operation of ESXi servers or their virtual machines, they would continue to function normally if vCenter or it’s database were unavailable (Except for DRS and vMotion which would not work). If the database were to crash and a new one created you could add your ESXi servers back in and it would repopulate the configuration information. The only data unique to the database is performance statistics, alarms, events, tasks, resource pools and custom attributes.

Read More

VMFS-5 Enhancements

•  Unified 1MB File Block Size. Previous versions of VMFS used 1,2,4 or 8MB file blocks. These larger blocks were needed to create large files (>256GB). Very large files can now be created on VMFS-5 using 1MB file blocks.
•  Large Single Extent Volumes. In previous versions of VMFS, the largest single extent (LUNs) was 2TB. With VMFS-5, this limit has been increased to ~ 60TB.
•  Smaller Sub-Block. VMFS-5 introduces a smaller sub-block. This is now 8KB rather than the 64KB we had in previous versions. Now small files < 8KB (but > 1KB) in size will only consume 8KB rather than 64KB. This will reduce the amount of disk space being stranded by small files.
• Small File Support. VMFS-5 introduces support for very small files. For files less than or equal to 1KB, VMFS-5 uses the file descriptor location in the metadata for storage rather than file blocks. When they grow above 1KB, these files will then start to use the new 8KB sub blocks. This reduce the amount of disk space being stranded by very small files.
•  Increased File Count. VMFS-5 introduces support for greater than 100,000 files, a three-fold increase on the number of files supported on VMFS-3, which was ~ 30,000.
•  ATS Enhancement. This Hardware Acceleration primitive, Atomic Test & Set (ATS), is now used throughout VMFS-5 for file locking. ATS is part of the VAAI (vSphere Storage APIs for Array Integration). This enhancement improves the file locking performance over previous versions of VMFS.

Differences between newly created and upgraded VMFS-5 datastores:

•     VMFS-5 upgraded from VMFS-3 continues to use the previous file block size which may be larger than the unified 1MB file block size.

•     VMFS-5 upgraded from VMFS-3 continues to use 64KB sub-blocks and not new 8K sub-blocks.

•     VMFS-5 upgraded from VMFS-3 continues to have a file limit of 30720 rather than new file limit of > 100000 for newly created VMFS-5.

•     VMFS-5 upgraded from VMFS-3 continues to use MBR (Master Boot Record) partition type; when the VMFS-5 volume is grown above 2TB, it automatically & seamlessly switches from MBR to GPT (GUID Partition Table) with no impact to the running VMs.

•     VMFS-5 upgraded from VMFS-3 continue to have its partition starting on sector 128; newly created VMFS5 partitions will have their partition starting at sector 2048.

RDM – Raw Device Mappings

•     There is now support for passthru RDMs (Physical Mode)  to be ~ 60TB in size.

•     Non-passthru RDMs (Virtual Mode) are still limited to 2TB – 512 bytes.

•     Both upgraded VMFS-5 & newly created VMFS-5 support the larger passthru RDM (Physical Mode)

Some More Information.

•     The maximum size of a VMDK on VMFS-5 is still 2TB -512 bytes.

•     The maximum size of a non-passthru (virtual) RDM on VMFS-5 is still 2TB -512 bytes.

•     The maximum number of LUNs that are supported on an ESXi 5.0 host is still 256.

Thanks to VMware, Information is from the white paper provided by VMware.

Read More

VMware Converter P2V / Cold Clone Process

The cold clone process when using the VMware Convert Cold Boot CD is pretty straight forward but in case anyone out there who haven’t tried using it before and would like to know what it looks like, this post serves to show the step-by-step instructions for using it to clone a physical server.
Before I start, I find that many people ask me why I prefer this cold clone process over a hot clone (live), the reasons are as follows:
Changes to the server if it’s left turned on.
Active Directory computer password changes.
Database applications (Exchange, SQL, etc).
Crash consistency.
I won’t go into the details but those are usually the key points I talk about when asked for justification. Unless the server has static content that doesn’t get updated dynamically and/or a server that is not joined to AD, I usually recommend shutting it down and cloning it this way.
Preparation
Prior to actually cloning, you should prepare as much information about your physical servers as possible. While the following list doesn’t cover all the items, it should give you an idea of what you need:
Inventory spreadsheet/documentation for the physical servers you’ll be virtualizing. This should include the current configuration, performance data (if possible), and virtualized configuration. The reason why you would need this information is because you may way to adjust settings such as number of CPUs or memory for the virtual machine as well as having to re-enter the IP once the p2v process has completed.
Prepare the VLANs required on your ESX/ESXi host. The last thing you want to do during the middle of the night of a p2v window is to scramble and figure out which VLAN you need to put those virtual machines on after you’re cloned them from the physical server. ESX/ESXi hosts are typically configured to use trunk ports for their NICs so plugging in a cable from your host to the port where your physical server used to be plugged in isn’t going to be an option.
Document and validate datastore for the virtual machine. Along with the inventory spreadsheet containing information about your physical servers, you should spend some time to right-size the virtual machines’ disks and ensure that all of them are going to fit onto the datastores(s) you’ll be using.
Prepare your cold clone CDs and make sure they have the proper drivers if you’re cloning old servers (whether on a CD, USB or injected into the cold clone CD). The cold clone CD doesn’t have drivers for all of the servers ever manufactured so there will be times where it won’t be able to read the physical server’s OS.
As I indicated earlier, this above is not a complete list so remember to add items to it during your planning and preparation phase.
Cold Clone Process
Once you’re ready to clone your physical server, insert the cold boot CD into the CD/DVD drive and boot from it. The following screen doesn’t show the option for hitting F6 to install drivers but you’ll see it upon booting into the cold boot CD’s WInPE OS:

As the WinPE’s VMware vCenter Converter boots, you’ll see a small status window indicating what’s being processed in the background:
Installing hardware devices
Setting display resolution
Starting networking
Finishing WinPE
Just before you actually get into the VMware vCenter Converter, you’ll be prompted for network settings. This screen is important because unless you use DHCP for your servers, you’ll need to assign the WinPE OS you’re booting in with an IP address, subnet mask, default gateway (if your vCenter is not on the same subnet) and DNS settings (if you choose to use the DNS name to get to your vCenter):

You’ll find that it’s confusing at times when you have more than 1 NIC port (most servers do) so what I typically do is just configure the first network adapter available and swap out the cable at the back of the server if necessary:

You’ll also find that you get options in the Advanced tab as you normally would if you navigate to the NIC’s properties in Windows:

I’ve actually never used the Network Drives tab before but it looks interesting:

Once you’ve completed configuring the network settings, you’ll see the following window of the VMware vCenter Converter:

You’ll notice that there are quite a few tabs available so before I start showing the process, I’ll paste the screenshots of the options available under each tab:

Now that I’ve shown all the options available under each tab, we proceed with clicking File –> New –> Import. This will start the vCenter Converter Import Wizard:

Proceed with clicking Next to allow vCenter Converter to detect the operating system of your physical host:

If you run into an error: Unable to determine Guest Operating System please click on below Link:
Click me

Once the operating system has been detected, you’ll see the following screen:

Typically don’t like to use the Import all disks and maintain size. option and prefer to use the Select volumes and resize to save or add space. option because you get more control over how the disks are virtualized. The options available will allow you to right-size the drives as you’ve planned during the planning phase:

I also find it important and consider it as best practice to check the Create a separate disk for each volume. option so that separate VMDKs are created for each disk. You’ll also sometimes find small partitions that are created by your server’s installation disks (usually recovery partitions) so uncheck those as you won’t need them once the virtual machine has been virtualized:

 

Once you’ve completed the configuration of the disks, continue on through the wizard:

Once you get to the following screen, choose the appropriate destination. Since we’re going to clone this physical server to the a vCenter server, choose the vSphere Virtual Machine option as the destination type:

The following screen will now allow you to enter the vCenter server address and credentials. I used to have problems back in the VI3 days where IPs didn’t appear to work but I have since tried both in vSphere and haven’t come across any problems so which one you use is up to you:

Once you’ve entered the credentials and click Next, the converter will reach out to your vCenter and validate the credentials:

If you’ve entered the incorrect credentials, you’ll see the following error message:
The system could not log you in. Please verify that the user name and password are correct, then try again. Passwords are case-sensitive.

Once the credentials have been validated, you’ll see the following screen where you can choose the virtual machine inventory location:

Proceeding to the next screen will give you the option of choosing which host, cluster or resource pool within a host or cluster you would like to place the virtual machine on:

The next screen will allow you to choose the specific host within the cluster you’ve chosen. This is important if you have servers that rely on other high availability options such as Windows NLB or MSCS where you would not want the active or passive node running on the same host:

Once you’ve selected the host you’d like the virtual machine to be hosted on, you’ll get to choose the datastore for the virtual machine:

The next screen will allow you to modify the NICs for the virtual machine. The wizard will always default to the amount of NICs that your physical server has so if you have more than you need, now is the time to change it. I also prefer to uncheck the Connect at powered on checkbox because I prefer to boot up the virtual machine after the p2v process has completed but it’s really just preference:

the next screen will give you the options:
Install VMware Tools
Customize the identity of the virtual machine
Remove all System Restore checkpoints
I usually prefer to select option #1 and # but not #2 because if I needed to change the virtual machine’s properties, I prefer to do it after it’s been virtualized.

The last screen will provide you with a summary of the virtual machine and what you’ve selected during the configuration as well as provide you with the option: Power on the new virtual machine after creation. While it’s not the default, I also select that option and this is why I prefer not to check the Connect at powered on checkbox:

Once you’ve completed the configuration through the import wizard, the task will start immediately as shown here:

How long the process will take always varies depending on how much data you need to virtualize and the network speed settings. Always remember to check what your physical server as well as your vCenter server network is connected at as there’s a significant difference between 100Mbps and 1Gbps.
As the process continues, you can monitor the progress in the Task Progress tab at the bottom of the window:

Once you’ve completed the cloning process, remember to perform cleanup tasks to remove any old vendor hardware specific devices hidden away in device manager. Also, newer versions of the converter typically fix the HAL for the process (Uniprocessor vs multiprocessor) but I always check the device manager to make sure it has been changed

Read More

Configuring HA on ESX hosts fails with the error: Cannot complete the configuration of the HA agent on the host (Re install HA agents)

Cannot configure HA on ESX hosts.
Unable to configure the aam agent.
Configuring HA on ESX hosts fails.
In vCenter Server one or more hosts in the HA cluster report the error:

Cannot complete the configuration of the HA agent on the host.

Resolution
This issue may occur if the vpxa agent on the ESX host is corrupted due to which you are unable to configure the aam agent.

Note: the below troubleshooting steps are not applicable to vCenter Server 5.0 as aam functionality is no longer used for HA on vCenter Server 5.0. For further HA (Fault Domain Manager) troubleshooting steps, see Troubleshooting Fault Domain Manager (FDM) problems (2004429).

To resolve this issue, remove the vpxa and aam agents from the ESX host and then reinstall them.

To remove the vpxa and aam agents:

Note: For information on reinstalling agents on an ESXi host, please reference KB 1027628
Connect to the ESX host using SSH.
Run this command to verify if the vpxa agent is installed:

# rpm -qa | grep vpxa

Note the vpxa package name returned by this command (For example, VMware-vpxa-#.#.#-#####).

Run this command to remove the vpxa agent:

# rpm -e <vpxa_package_name>

Where <vpxa_package_name> is the vpxa package name noted in Step 2.

For example:

# rpm -e VMware-vpxa-#.#.#-#####

Run this command to verify if the aam agent is installed:

# rpm -qa | grep aam

Note the two aam package names returned by this command. For example, VMware-aam-haa-#.#.#-# and VMware-aam-vcint-#.#.#-#.

Run this command to remove the aam package files:

rpm -e <aam_package_name>

Where <aam_package_name> is the aam package name noted in Step 4.

For example:

rpm -e VMware-aam-haa-#.#.#-#
rpm -e VMware-aam-vcint-#.#.#-#
To reinstall vpxa and aam agents:

Move the vpxa and aam agent installation files from vCenter Server to the ESX host using a secured file transfer utility, such as WinSCP.

Note: To download WinSCP, see http://winscp.net/.

To move files using WinSCP:
Open WinSCP and browse to C:\Program Files\VMware\Infrastructure\VirtualCenter Server\upgrade.
Upload these files to the /tmp directory of the ESX host (chose the highest available Build number):
vpx-upgrade-esx-7-linux-[BuildNumber]
aam-upgrade-esx-xxxxxxxx-[BuildNumber]prod-kcc-vip.vmware.com:8080/contactcenter/authoring/search.do?cmd=displayKC

Connect to the ESX host using SSH.
Browse to the /tmp directory.
Run these commands to install the agents:

# sh vpx-upgrade-esx-7-linux-[BuildNumber]
# sh aam-upgrade-esx-xxxxxxxx-[BuildNumber]

Run these commands to verify if the agents are installed:

# rpm -qa | grep vpxa
# rpm -qa | grep aam

Run these commands to restart services on the host:

# service mgmt-vmware restart
# service vmware-vpxa restart

Add the host back to vCenter Server.
Note: If the issue persists, disable and re-enable VMware High Availability in the cluster.

Read More

ESXi 5 Tips & Tricks: Disable Tech Support Mode Warnings

ESX is officially gone and VMware has made the succession to ESXi complete. Still, some of us might want to log into ESXi's shell by enabling Tech Support Mode or Remote Tech Support via SSH. Now by enabling one of these two support modes, a yellow warning will appear on the host object in vCenter. If you select the Summary tab of the actual host itself, you will see a couple of messages that are immediately apparent:

ESXi Shell for the host has been enabled
SSH for the host has been enabled
In VMware's defense, it most certainly didn't enable those warning just to annoy us. Enabling Shell and SSH remote access should be used for a limited time for technical support purposes. Security best practices dictate that you keep these disabled--hence, the warning messages. Administering or managing your ESXi host from the command line should be done using the vSphere Management Assistant appliance (vMA) or by installing PowerShell.

That being said, some of us understand the security risks and still want to enable shell access or remote access via SSH, but do not want to see the annoying warning messages that are there just to disturb our perfectly harmonious and well-oiled vSphere infrastructures. To those vNerds I give you three ways of disabling these warnings:

Command line:
esxcli system settings advanced set -o /UserVars/ESXiShellTimeOut -i 1
Scripted installs you set:
/adv/UserVars/SuppressShellWarning = "1"
The third method is through the GUI, as follows:

Select your ESXi host and go to the Configuration tab (yes, it has to be done on every host, so use scripted installs to set this if you will deploy on all hosts as a standard)
Click on the Advanced Settings node on the left
Select the UserVars node on the left
Locate "UserVars.SuppressShellWarning" and set the value to 1. (By default, it is set to 0.)
You can disable the warning messages without rebooting the ESXi host or placing it in maintenance mode. For more information about this, check out VMware KB 2003637.

Read More

Understanding/Using log files for troubleshooting

Log files are generally your best tool for troubleshooting any type of problem. ESX has many log files. Which ones you should check depends on the problem you are experiencing. Below is the list of ESX log files that you will commonly use to troubleshoot ESX server problems. The VMkernel and hosted log files are usually the logs you will want to check first.
• VMkernel - /var/log/vmkernel – Records activities related to the virtual machines and ESX server. Rotated with a numeric extension, current log has no extension, most recent has a ".1" extension.
• VMkernel Warnings - /var/log/vmkwarning – Records activities with the virtual machines, a subset of the VMkernel log and uses the same rotation scheme.
• VMkernel Summary - /var/log/vmksummary - Used to determine uptime and availability statistics for ESX Server; readable summary found in /var/log/vmksummary.txt.
• ESX Server host agent log - /var/log/vmware/hostd.log - Contains information on the agent that manages and configures the ESX Server host and its virtual machines. (Search the file date/time stamps to find the log file it is currently outputting to, or open hostd.log, which is linked to the current log file.)
• ESX Firewall log - /var/log/vmware/esxcfg-firewall.log – Logs all firewall rule events.
• ESX Update log - /var/log/vmware/esxupdate.log – Logs all updates done through the esxupdate tool.
• Service Console - /var/log/messages - Contains all general log messages used to troubleshoot virtual machines or ESX Server.
• Web Access - /var/log/vmware/webAccess - Records information on web-based access to ESX Server.
• Authentication log - /var/log/secure - Contains records of connections that require authentication, such as VMware daemons and actions initiated by the xinetd daemon.
• Vpxa log - /var/log/vmware/vpx - Contains information on the agent that communicates with VirtualCenter. Search the file date/time stamps to find the log file it is currently outputting to or open hostd.log which is linked to the current log file.
As part of the troubleshooting process, often times you'll need to find out the version of various ESX components and which patches are applied. Below are some commands you can run from the service console to do this:
• Type vmware –v to check ESX Server version, i.e., VMware ESX Server 3.0.1 build-32039
• Type esxupdate –l query to see which patches are installed.
• Type vpxa –v to check the ESX Server management version, i.e. VMware VirtualCenter Agent Daemon 2.0.1 build-40644.
• Type rpm –qa | grep VMware-esx-tools to check the ESX Server VMware Tools installed version – i.e., VMware-esx-tools-3.0.1-32039.

Read More

Unable to connect MKS

1) MKS console fails to open with the error: the process /usr/lib/bin/vmware-vmkauthd-start failed to launch properly 
This issue occurs when the vmware-vmkauthd service cannot start due to insufficient memory. To resolve this issue, be sure to maintain adequate memory levels.
To ensure adequate available memory:
Check for resource pools having reservations over all available memory. If resource pools that exceed all available physical memory are detected, change the settings to ensure adequate space for system usage. For more information, see the Resource Management Guide for your version of ESX: 3.0 3.5 4.0 4.1
Restart the vmware-vmkauthd service using thiscommand:

#service vmware-vmkauthd restart
If the service was hung, it may still be running. In this case, run this command to kill the process:

#kill -9 <PID>

where <PID> is the PID of the service.
Run this command to start the service:

#service vmware-vmkauthd start
=================================
2) Unable to connect to the MKS: Error connecting to d:\Program Files (x86)\VMware\VMware server\x64\vmware-vmx.exe process.
If a virtual machine's console is blank VirtualCenter, restart the VirtualCenter Server.
-go into admin tools -&gt; services
-locate the VMWare Authorization service
-change the log on from Local System to a domain admin account.
-apply and ok. It will prompt you to restart the service to take affect, do this.
-if you try to log into the web interface and start a VM, you will get an access denied message
-go back into the VMware Authorization service, and change it back to Local System account, and restart the agent
====================================
3) Unable to connect to the MKS: Error
Kill any vmware-serverd processes with:
killall vmware-serverd
or
killall -9 vmware-serverd
Restart httpd with:
service httpd.vmware restart
The vmware-serverd processes should respawn automatically.
====================================
4) In the unlikely event that xinetd is not listening on port 902 for incoming ESX Server authd requests, you can restart xinetdusing:

service xinetd restart
====================================
5) VMware: VM Console error: Unable to connect to the MKS: Failed to connect to the server
To avoid losing access to the ESX host, perform the following steps:
Add the ESX server in your DNS
Edit your hostfile on the workstation (C:\Windows\System32\Drivers\etc\hosts\) and add your ESX server
===================================
6) VMware ESX Error: Unable to connect to the MKS: vmx connection handshake failed for mks of…
Edit the settings of the virtual machine, click the Options tab and make sure that the guest operating system version is correct. This can cause this error, so make sure you select the correct OS. E.g. “Microsoft Windows Server 2008 R2 (64-bit)”.
Try removing the virtual machine from the vCenter inventory and re-adding it.
Try restarting the VMware management agents (service mgmt-vmware restart and service vmware-vpxa restart).
===================================
7) When opening a virtual machine remote console you receive the error: Unknown MKS event
This issue occurs if TCP Port 903 is blocked. VMware Remote Console traffic flows directly over TCP port 903 between the workstation running the vCenter client and the ESX host.
Unblock TCP Port 903 in your firewall to resolve this issue. Refer to the firewall documentation or contact the firewall vendor's support for assistance in unblocking this port.
===================================  A virtual machine's console in VirtualCenter is blank and shows the message: Unknown MKS event
If a virtual machine's console is blank VirtualCenter, restart the VirtualCenter Server. For more information, see Stopping, starting, or restarting vCenter services (1003895).
===================================
9) Opening a console to a virtual machine fails with the error: Unable to connect to the MKS: Console access to the virtual machine cannot be granted since the connection limit of 0 has been reached
Open a session to the vSphere Web Client.

https://vcenter_server_name:9443/vsphere-client
After connecting, right-click the affected virtual machine.
Click Configuration > Edit Settings....
Click VM options.
Click VMware Remote Console Options, then deselect Limit the number of simultaneous connections to this Virtual Machine.
Click OK.
Open a new console window to the virtual machine in the vSphere Client to verify.
Alternatively, add an entry to the configuration parameters of the virtual machine:
Power off the virtual machine.
Right-click the affected virtual machine and select Edit Settings....
Click the Options tab, then click General under Advanced.
Click Configuration Parameters....
Look for an entry named RemoteDisplay.maxConnections.
If the entry exists, set the Value to 1 or higher.
If the entry does not exist, click Add Row to add the parameter. The parameter details are:

Name: RemoteDisplay.maxConnections
Value: 10

Note: The Value can be set to 1 or more.
Power on the virtual machine.
Open a new console window to the virtual machine in the vSphere Client to verify.

Read More

VMware ESXi 5 Install

1. Either burn or mount the ESXi 5 iso image to the DVD drive of the server and let the server boot from dvd.

2. The dvd continues to boot.

3. Press enter to continue at the Welcome to VMware ESXi 5 Installation screen.

4. Press F11 to accept the End User License Agreement.

5. Select the hard drive you wish to install VMware ESXi 5 onto and press Enter.

6. Select your keyboard layout and press Enter.

7. VMware have added in this step as opposed to previous version. Here we will enter in the root password that we wish to use. In previous version you would enter in the root password after ESXi is installed. When you are finished press enter.

8. Press F11 to begin installing ESXi 5.

9. The installation process.

10. Once the installation is complete you are required to reboot the server. Press enter.

11. VMware ESXi 5 is now installed. Move onto the next tutorial to begin setting a static ipaddress, dns, etc.

Installing VMware ESXi 5 Video Tutorial

Read More

First Blog Entry !!!

Thanks for visiting Our site! this blog will mostly contain articles about  virtualization stuff (VMware).  we started this blog for only two reasons, first of all we enjoy sharing our knowledge and secondly memorizing all the problems, Queries and solutions is not an easy task to remember, this blog help to retain that knowledge.

See you Around !!

Thanks Again

Asim

Read More