Latest Posts



Translate

Total Pageviews

Sunday, 31 January 2016

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:

For more information, see:
Source:-

Saturday, 30 January 2016

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.

Friday, 29 January 2016

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

 

Thursday, 28 January 2016

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.

ServiceService Account
VMware Component ManagerNT SERVICE\VMwareComponentManager
VMware Content Library ServiceNT SERVICE\vdcs
VMware ESX Agent ManagerNT SERVICE\EsxAgentManager
VMware Message Bus Config ServiceNT SERVICE\mbcs
VMware Performance ChartsNT SERVICE\vmware-perfcharts
VMware PostgresNT SERVICE\vPostgres
VMware vAPI EndpointNT SERVICE\vapiEndpoint
VMware vCenter workflow managerNT SERVICE\vmware-vpx-workflow
VMware vService Manager NT SERVICE\VServiceManager
VMware vSphere Audo Deploy WaiterNT SERVICE\vmware-autodeploy-waiter
VMware vSphere Web ClientNT 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 NameDescription
applmgmtVMware Appliance Management Service
vmware-cis-licenseVMware License Service
vmware-cmVMware Component Manager
vmware-eamVMware ESX Agent Manager
vmware-sts-idmdVMware Identity Management Service
vmware-invsvcVMware Inventory Service
vmware-mbcsVMware Message Bus Configuration Service
vmware-netdumperVMware vSphere ESXi Dump Collector
vmware-perfchartsVMware Performance Charts
vmware-rbd-watchdogVMware vSphere Auto Deploy Waiter
vmware-rhttpproxyVMware HTTP Reverse Proxy
vmware-scaVMware Service Control Agent
vmware-spsVMware vSphere Profile-Driven Storage Service
vmware-stsdVMware Security Token Service
vmware-syslogVMware Common Logging Service
vmware-syslog-healthVMware Syslog Health Service
vmware-vapi-endpointVMware vAPI Endpoint
vmware-vdcsVMware Content Library Service
vmafddVMware Authentication Framework
vmcadVMware Certificate Service
vmdirdVMware Directory Service
vmware-vpostgresVMware Postgres
vmware-vpx-workflowVMware vCenter Workflow Manager
vmware-vpxdVMware vCenter Server
vmware-vsmVMware vService Manager
vsphere-clientvSphere Web Client
vmware-vwsVMware System and Hardware Health Manager

Sunday, 24 January 2016

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
 

Thursday, 21 January 2016

Automating Actions in vRealize Operations Manager

Part 1:-

Part 2:-

Source:-
Youtube VMware

Tuesday, 19 January 2016

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.