Support for virtual machine disks larger than 2 TB in VMware ESXi 5.5 (2058287)

Purpose

VMware ESXi 5.5 introduces supportability for virtual machine disks (VMDKs) larger than 2 TB. 

This article provides information on the conditions and limitations of large capacity virtual disks in ESXi 5.5.

Resolution

In vSphere 5.5, large capacity virtual disks have these conditions and limitations:

• An ESXi 5.5 or later host is required.
• The maximum supported VMDK size on an VMFS-5 datastore is increased to 62 TB. However, the maximum supported VMDK size on VMFS-3 is still 2 TB.
• The maximum supported size of a VMDK on NFS is the lesser of 62 TB and 1% less than the maximum file size supported by the NFS filesystem.
  
  Notes:
  
  • The largest file size depends on the underlying file system (for example, 16 TB on ext3).
  • A maximum of 62 TB is enforced, even if the underlying NFS filesystem supports a greater size.
• The maximum supported size of a virtual mode Raw Device Mapping (vRDM) has also been increased from 2 TB to 62 TB.
• A VMDK larger than 2 TB can be created on a virtual machine that is powered on or off, but extending a VMDK beyond 2 TB is only supported when the virtual machine is powered off.
• You must use the vSphere Web Client to create or extend a VMDK beyond 2 TB. For more information, see the Troubleshootingsection.

Virtual machines with large capacity disks have these conditions and limitations:

• The guest operating system must support large capacity virtual hard disks.
• You can only move or clone disks that are greater than 2 TB to ESXi 5.5 hosts, or to clusters that have such hosts available.
• The datastore format must be VMFS-5 or later, or an NFS volume on a Network Attached Storage (NAS) server.
• vSphere Flash Read Cache supports a maximum hard disk size of 16 TB.
• VMFS-3 volumes are not supported. You cannot move disks greater than 2 TB from a VMFS-5 datastore to a VMFS-3 datastore.
• You cannot hot-extend a virtual disk if the capacity after extending the disk is equal to or greater than 2 TB. Only offline extension of GPT-partitioned disks beyond 2 TB is possible.
• Fault Tolerance is not supported.
• Virtual SAN is not supported.
• BusLogic parallel controllers are not supported.
• Virtual machines with large capacity virtual hard disks or disks greater than 2 TB must meet resource and configuration requirements for optimal virtual machine performance. The maximum value for large capacity hard disks is 62 TB. When you add or configure virtual disks, always leave a small amount of overhead. Some virtual machine tasks can quickly consume large amounts of disk space, which can prevent successful completion of the task if the maximum disk space is assigned to the disk. Such events might include taking snapshots or using linked clones. These operations cannot finish when the maximum amount of disk space is allocated.
• In environments without shared storage, operations such as snapshot quiesce, cloning, Storage vMotion, or vMotion can take significantly longer to finish.
• You cannot relocate RDMs larger than 2 TB to datastores other than VMFS-5 or, to hosts older than ESXi 5.5.
• To enable the Microsoft Windows operating system to address a maximum storage capacity for a device greater than 2 TB, the disk must be initialized by using the GUID partition Table (GPT) partitioning scheme. For more information, see Windows support for hard disks that are larger than 2 TB.
  
  Note: The preceeding link was correct as of September 8, 2014. If you find the link is broken, please provide feedback and a VMware employee will update the link.

Changes in virtual machine snapshots for VMDKs larger than 2 TB:

• Snapshots taken on VMDKs larger than 2 TB are now in Space Efficient Virtual Disk (SESPARSE) format. No user interaction is required. The redo logs are automatically created as SESPARSE instead of VMFSSPARSE (delta) when the base flat VMDK is larger than 2 TB.
• Extending a base flat disk on VMFSSPARSE or SESPARSE is not supported.
• The VMFSSPARSE format does not have the ability to support 2 TB or more.
• VMFSSPARSE and SESPARSE formats cannot co-exist in the same VMDK. In a virtual machine, both types of snapshot can co-exist, but not in the same disk chain. For example, when a snapshot is taken for a virtual machine with two virtual disks attached, one smaller than 2 TB and one larger than 2 TB, the smaller disk snapshot are VMFSSPARSE the larger disk snapshot are SESPARSE.
• Linked clones are SESPARSE if the parent disk is larger than 2 TB.

Troubleshooting

• When you attempt to extend a VMDK beyond 2 TB on a powered on virtual machine, you see this error in the client:
  
  Hot-extend was invoked with size (*** sectors) > =2TB. Hot-extend beyond or equal to 2TB is not supported. This disk extend operation failed: msg.disklib.INVAL
  
  To resolve this issue:
  
  
  • Power off the virtual machine and retry the extend operation.
  • Detach the VMDK from the original virtual machine and attach to any other powered off virtual machine and then increase the size to the desired size. Detach the VMDK from the temporary powered off vm and attach back to the original Virtual machine
• When you attempt to create a large virtual disk on a VMFS-3 datastore or on NFS using ext3, you see this error in the vSphere Client or when using vmkfstools:
  
  Failed to create virtual disk: The destination file system does not support large files (12).
• When you attempt to create a large VMDK using the vSphere Client, you see the error:
  
  The disk capacity entered was not a properly formed number or was out of range. It has been replaced with the nearest acceptable value
DiskCapControl : value 6924239004288 is out of range (1048576,4398046511104)
  
  Checking the size of the newly created or expanded VMDK, you find that it is 4 TB.
  
  To resolve this issue:
  
  
  • Use the vSphere Web Client to create VMDKs larger than 4 TB, or to extend an existing VMDK beyond 4 TB.
  • Use the vSphere CLI or vmkfstools to extend or create VMDKs larger than 4 TB. For more information, see Adding space to an ESXi/ESX host virtual disk (994) and step 5 in Recreating a missing virtual machine disk (VMDK) descriptor file (1002511).

For more information, see:

• Value out of range error message when adding disks larger than 4TB in vSphere Client (2054952).
• Cannot Consolidate Snapshots for Large-Capacity Disks section of the vSphere 5.5 Troubleshooting Guide.

Source:-

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2058287&src=vmw_so_vex_ragga_1012

Request is IN PROGRESS in vCAC 6.2 - How to delete it?

In vCAC (or vRealize Automation now), many requests were blocked in status “In Progress” since few weeks or months!

In this POST i will discuss how to delete or clean up those IN PROGRESS request. Here i will demonstrate how to delete them from database.

In this Example the Request Number is 6. In my case i took the screenshot after deleting the request 6 so you will not get the visibility of request number 6 in below given screenshot. But this is the place where you can check the request information.

Steps:-
1. Connect with vCAC/vRA appliance through SSH client like Putty
2. Go to the bin directory of vPostgres
cd /opt/vmware/vpostgres/9.2/bin/·

 3. Connect to the vcac database with the username”vcac”

4.  To Get the request ID of request number 6
SELECT id,requestnumber FROM cat_request where state=’IN_PROGRESS’ and requestnumber = 'RequestNum';

5. Then Execute this command:-
delete from cat_requestevent_details where requestevent_id in(select id from cat_requestevent where request_id =''); 

The return can be 0.

6. Execute this Command
delete from cat_requestevent where request_id = ”;

The return will be 3. 

7.  Now execute this Command
delete from cat_request where id =’ID’;

The return will be 1.
 
8. Finally exit from psql by using this command
\q and Press Enter

Now refresh your web browser and request will now no more there. Repeat the same procedure for the remaining IN PROGRESS requests.

Source:-
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2114385&src=vmw_so_vex_ragga_1012 

401 - Unauthorized: Access is denied due to invalid credentials. You do not have permission to view this directory or page using the credentials that you supplied.

Issue:-
Unauthorized: Access is denied due to invalid credentials. You do not have permission to view this directory or page using the credentials that you supplied. while requesting a Service in vRealize Automation.

Reason:-
It was because of vCenter Inventory Service.

Solution:-
Restart vCenter Inventory Service.

Restore the vCenter Server 6.0 Appliance vPostgres Database

Backing up and restoring your database protects the data stored in your database. When you install vCenter Server, if you want to use the embedded vPostgres database and later have to uninstall vCenter Server, all data is lost, because the embedded vPostgres database is also uninstalled.
To minimize the risk of data loss, you must regularly back up and restore the vPostgres database in both vCenter Server and the vCenter Server Appliance.
 
Note: This article is only supported for backup and restore of the vPostgres database to the same vCenter Server or vCenter Server Appliance. Use of image-based backup and restore is the only solution supported for performing a full, secondary appliance restore.


• Visit the KB article and download the linux_backup_restore.zip file.  Extract restore_lin.py script to the desktop
• SSH to the vCenter 6.0 appliance and login as root
• To enable the bash shell
Type shell.set --enabled true
• To access the bash shell
Type shell
• To change the default shell to bash
Type chsh -s /bin/bash root
• Using WinSCP, connect to vCenter 6.0 appliance and transfer the restore_lin.py file and the backup_VCDB.bak database file from the desktop backup folder.  Make a note of where you transfer the files (/root is a good place).
• Return to the ssh session and change directory to where you placed the restore file and database
• To make it executable
Enter chmod 700 ./restore_lin.py
• Stop the vmware-vpxd and vmware-vdcs services:
service vmware-vpxd stop
service vmware-vdcs stop
• Enter python ./restore_lin.py -f backup_VCDB.bak and wait for the restore to complete (You should see "Restore completed successfully.")
• Start the vmware-vpxd and vmware-vdcs services:
service vmware-vpxd start    
service vmware-vdcs start

 

Use of virtual accounts for services on a Windows vCenter Server 6.0 (2124709)

Purpose

Starting in vCenter Server 6.0 for Windows, virtual accounts replace the Local Service Account used in vCenter Server 5.x to run the vCenter Server services. This article contains information on the impacts it will have on your environment.

Resolution

Virtual accounts in vSphere 6.0 for Windows increase the security of vCenter Server by disallowing privilege escalation within the host operating system in the event that a single service becomes compromised. Because all services are placed into their own silo using virtual accounts. Even when a user gains access to a single virtual account, they are limited only to the functionality of that account and also limited to only that single service. This ensures that the vSphere 6.0 environment is running on a minimum set of privileges that is dependent on the specific service.

The following virtual accounts are now used as the service accounts to run their respective service.

Service	Service Account
VMware Component Manager	NT SERVICE\VMwareComponentManager
VMware Content Library Service	NT SERVICE\vdcs
VMware ESX Agent Manager	NT SERVICE\EsxAgentManager
VMware Message Bus Config Service	NT SERVICE\mbcs
VMware Performance Charts	NT SERVICE\vmware-perfcharts
VMware Postgres	NT SERVICE\vPostgres
VMware vAPI Endpoint	NT SERVICE\vapiEndpoint
VMware vCenter workflow manager	NT SERVICE\vmware-vpx-workflow
VMware vService Manager	NT SERVICE\VServiceManager
VMware vSphere Audo Deploy Waiter	NT SERVICE\vmware-autodeploy-waiter
VMware vSphere Web Client	NT SERVICE\vspherewebclientsvc

Notes:

• Future releases of vSphere uses unique virtual accounts for all services. However, vSphere 6.0 is limited to the preceding list.
• Do not change these accounts after they are established.

Source:-

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2124709&src=vmw_so_vex_ragga_1012

Unable to Power on VM in vCenter 6 - A general system error occurred: Connection refused

Issue:-
Today when i was trying to power on one of my VM in vSphere 6 Environment it's getting failed with message "A general system error occurred: Connection refused".

Then i tried to power on this VM by directly connecting with my ESXi Host from vSphere Client and i was able to power on my vm then question was why i cannot start the same VM if i am connected with my ESXi host through vCenter. Then i found a KB article from VMware on How to start/stop the services in vCenter Server Appliance Version 6.

Reason:-
VMware vCenter Workflow Manager Service was Stopped.
1. To get in to vCSA 6.0 Shell
    (a). I accessed my  vCSA 6.0 through Putty
    (b). Then to enable BASH access i executed this command
           shell.set --enabled True
    (c) Then to Launch BASH i executed this command
          shell

service-control --status vmware-vpx-workflow
 

Solution:-
Start the VMware vCenter Workflow Manager Service

service-control --start vmware-vpx-workflow

 After this i tried to Power On the VM again and i was able to power it on.

vCenter Server Appliance services:-

Service Name	Description
applmgmt	VMware Appliance Management Service
vmware-cis-license	VMware License Service
vmware-cm	VMware Component Manager
vmware-eam	VMware ESX Agent Manager
vmware-sts-idmd	VMware Identity Management Service
vmware-invsvc	VMware Inventory Service
vmware-mbcs	VMware Message Bus Configuration Service
vmware-netdumper	VMware vSphere ESXi Dump Collector
vmware-perfcharts	VMware Performance Charts
vmware-rbd-watchdog	VMware vSphere Auto Deploy Waiter
vmware-rhttpproxy	VMware HTTP Reverse Proxy
vmware-sca	VMware Service Control Agent
vmware-sps	VMware vSphere Profile-Driven Storage Service
vmware-stsd	VMware Security Token Service
vmware-syslog	VMware Common Logging Service
vmware-syslog-health	VMware Syslog Health Service
vmware-vapi-endpoint	VMware vAPI Endpoint
vmware-vdcs	VMware Content Library Service
vmafdd	VMware Authentication Framework
vmcad	VMware Certificate Service
vmdird	VMware Directory Service
vmware-vpostgres	VMware Postgres
vmware-vpx-workflow	VMware vCenter Workflow Manager
vmware-vpxd	VMware vCenter Server
vmware-vsm	VMware vService Manager
vsphere-client	vSphere Web Client
vmware-vws	VMware System and Hardware Health Manager

Use of More and Less Command

I have been always asked in my sessions that what is difference between more and less. 

More

esxcli --help | more
 
a. Use the more command to scroll down. The more command scrolls down only.
b. Press the space bar to scroll one screen at a time.
c. Press Enter to advance one line at a time.
 
Less

esxcli --help | less
 
a. Use the less command to scroll up and down in the input.
b. Press Ctrl+F to go forward in the output.
c. Press Ctrl+B to go backward in the output.
d. Use the up and down arrow keys to navigate backward and forward one line at a time.
e. Press q to quit the less command and return to the command line
 

Automating Actions in vRealize Operations Manager

Part 1:-

Part 2:-

Source:-
Youtube VMware

vSphere Network Rollback

Rollback is enabled by default. However, you can enable or disable rollbacks at the vCenter Server level.

Several networking events can trigger a rollback. The events are grouped into these categories:

• Host networking rollbacks (virtual switches or network system)
• Distributed switch rollbacks

Source: VMware KB 2032908

 

Host Networking Rollbacks

Host networking rollbacks occur when an invalid change is made to the host networking configuration. Every network change that disconnects a host also triggers a rollback. These changes to the host networking configuration are examples of what might trigger a rollback:

• Updating the speed or duplex of a physical NIC
• Updating DNS and routing settings
• Updating teaming and failover policies or traffic shaping policies of a standard port group that contains the management VMkernel network adapter
• Updating the VLAN of a standard port group that contains the management VMkernel network adapter
• Increasing the MTU of management VMkernel network adapters and its switch to values not supported by the physical infrastructure
• Changing the IP settings of management VMkernel network adapters
• Removing the management VMkernel network adapter from a standard or distributed switch
• Removing a physical NIC of a standard or distributed switch containing the management VMkernel network adapter

If a network disconnects for any of these reasons, the task fails and the host reverts to the last valid configuration.

Distributed Switch Rollbacks

Distributed switch rollbacks occur when invalid updates are made to distributed switch-related objects, such as distributed switches, distributed port groups, or distributed ports. These changes to the distributed switch configuration might trigger a rollback:

• Changing the MTU of a distributed switch
• Changing the following settings in the distributed port group of the management VMkernel network adapter
• Teaming and failover
• VLAN
• Traffic shaping
• Blocking all ports in the distributed port group containing the management VMkernel network adapter
• Overriding the policies above for the distributed port to which the management VMkernel network adapter is connected

If an invalid configuration for any of the changes occurs, one or more hosts might be out of synchronization with the distributed switch.