Permanent Device Loss (PDL) and All-Paths-Down (APD) in vSphere 5.x


Permanent Device Loss (PDL)

  • A datastore is shown as unavailable in the Storage view.
  • A storage adapter indicates the Operational State of the device as Lost Communication.
  • All paths to the device are marked as Dead.
  • The /var/log/vmkernel.log file shows messages similar to:

    cpu2:853571)VMW_SATP_ALUA: satp_alua_issueCommandOnPath:661: Path "vmhba3:C0:T0:L0" (PERM LOSS) command 0xa3 failed with status Device is permanently unavailable. H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x25 0x0.
    cpu2:853571)VMW_SATP_ALUA: satp_alua_issueCommandOnPath:661: Path "vmhba4:C0:T0:L0" (PERM LOSS) command 0xa3 failed with status Device is permanently unavailable. H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x25 0x0.
    cpu2:853571)WARNING: vmw_psp_rr: psp_rrSelectPathToActivate:972:Could not select path for device "naa.60a98000572d54724a34642d71325763".
    cpu2:853571)WARNING: ScsiDevice: 1223: Device :naa.60a98000572d54724a34642d71325763 has been removed or is permanently inaccessible.
    cpu3:2132)ScsiDeviceIO: 2288: Cmd(0x4124403c1fc0) 0x9e, CmdSN 0xec86 to dev "naa.60a98000572d54724a34642d71325763" failed H:0x8 D:0x0 P:0x0
    cpu3:2132)WARNING: NMP: nmp_DeviceStartLoop:721:NMP Device "naa.60a98000572d54724a34642d71325763" is blocked. Not starting I/O from device.
    cpu2:2127)ScsiDeviceIO: 2316: Cmd(0x4124403c1fc0) 0x25, CmdSN 0xecab to dev "naa.60a98000572d54724a34642d71325763" failed H:0x1 D:0x0 P:0x0 Possible sense data: 0x5 0x25 0x0.
    cpu2:854568)WARNING: ScsiDeviceIO: 7330: READ CAPACITY on device "naa.60a98000572d54724a34642d71325763" from Plugin "NMP" failed. I/O error
    cpu2:854568)ScsiDevice: 1238: Permanently inaccessible device :naa.60a98000572d54724a34642d71325763 has no more open connections. It is now safe to unmount datastores (if any) and delete the device.
    cpu3:854577)WARNING: NMP: nmpDeviceAttemptFailover:562:Retry world restore device "naa.60a98000572d54724a34642d71325763" - no more commands to retry

All-Paths-Down (APD)

  • A datastore is shown as unavailable in the Storage view.
  • A storage adapter indicates the Operational State of the device as Dead or Error.
  • All paths to the device are marked as Dead.
  • You are unable to connect directly to the ESXi host using the vSphere Client.
  • The ESXi host shows as Disconnected in vCenter Server.
  • The /var/log/vmkernel.log file shows messages similar to:

    cpu1:2049)WARNING: NMP: nmp_IssueCommandToDevice:2954:I/O could not be issued to device "naa.60a98000572d54724a34642d71325763" due to Not found
    cpu1:2049)WARNING: NMP: nmp_DeviceRetryCommand:133:Device "naa.60a98000572d54724a34642d71325763": awaiting fast path state update for failover with I/O blocked. No prior reservation exists on the device.
    cpu1:2049)WARNING: NMP: nmp_DeviceStartLoop:721:NMP Device "naa.60a98000572d54724a34642d71325763" is blocked. Not starting I/O from device.
    cpu1:2642)WARNING: NMP: nmpDeviceAttemptFailover:599:Retry world failover device "naa.60a98000572d54724a34642d71325763" - issuing command 0x4124007ba7c0
    cpu1:2642)WARNING: NMP: nmpDeviceAttemptFailover:658:Retry world failover device "naa.60a98000572d54724a34642d71325763" - failed to issue command due to Not found (APD), try again...
    cpu1:2642)WARNING: NMP: nmpDeviceAttemptFailover:708:Logical device "naa.60a98000572d54724a34642d71325763": awaiting fast path state update...
    cpu0:2642)WARNING: NMP: nmpDeviceAttemptFailover:599:Retry world failover device "naa.60a98000572d54724a34642d71325763" - issuing command 0x4124007ba7c0
    cpu0:2642)WARNING: NMP: nmpDeviceAttemptFailover:658:Retry world failover device "naa.60a98000572d54724a34642d71325763" - failed to issue command due to Not found (APD), try again...
    cpu0:2642)WARNING: NMP: nmpDeviceAttemptFailover:708:Logical device "naa.60a98000572d54724a34642d71325763": awaiting fast path state update...

  • A restart of the management agents may show these errors:

    Not all VMFS volumes were updated; the error encountered was 'No connection'.
    Rescan complete, however some dead paths were not removed because they were in use by the system. Please use the 'storage core device world list' command to see the VMkernel worlds still using these paths.
    Error while scanning interfaces, unable to continue. Error was Not all VMFS volumes were updated; the error encountered was 'No connection'.

  • You may also see that the device is no longer listed:

    cpu17:10107)WARNING: Vol3: 1717: Failed to refresh FS 4beb089b-68037158-2ecc-00215eda1af6 descriptor: Device is permanently unavailable
    cpu17:10107)ScsiDeviceIO: 2316: Cmd(0x412442939bc0) 0x28, CmdSN 0x367bb6 from world 10107 to dev "eui.00173800084f0005" failed H:0x1 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0.
    cpu17:10107)Vol3: 1767: Error refreshing PB resMeta: Device is permanently unavailable


This article discusses a Permanent Device Loss (PDL) and All-Paths-Down (APD) in ESXi 5.x, and provides information on dealing with each of these scenarios.


In vSphere 4.x, an All-Paths-Down (APD) situation occurs when all paths to a device are down. As there is no indication whether this is a permanent or temporary device loss, the ESXi host keeps reattempting to establish connectivity. APD-style situations commonly occur when the LUN is incorrectly unpresented from the ESXi/ESX host. The ESXi/ESX host, still believing the device is available, retries all SCSI commands indefinitely. This has an impact on the management agents, as their commands are not responded to until the device is again accessible. This causes the ESXi/ESX host to become inaccessible/not-responding in vCenter Server.

In vSphere 5.x, a clear distinction has been made between a device that is permanently lost (PDL) and a transient issue where all paths are down (APD) for an unknown reason.

For example, in the VMkernel logs, if a SCSI sense code of H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x25 0x0 or Logical Unit Not Supported is logged by the storage device to the ESXi 5.xhost, this indicates that the device is permanently inaccessible to the ESXi host, or is in a Permanent Device Loss (PDL) state. The ESXi host no longer attempts to re-establish connectivity or issue commands to the device.

Devices that suffer a non-recoverable hardware error are also recognized as being in a Permanent Device Loss (PDL) state.

This table outlines possible SCSI sense codes that determine if a device is in a PDL state:

SCSI sense code Description
H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x25 0x0 LOGICAL UNIT NOT SUPPORTED
H:0x0 D:0x2 P:0x0 Valid sense data: 0x4 0x4c 0x0 LOGICAL UNIT FAILED SELF-CONFIGURATION
H:0x0 D:0x2 P:0x0 Valid sense data: 0x4 0x3e 0x3 LOGICAL UNIT FAILED SELF-TEST
H:0x0 D:0x2 P:0x0 Valid sense data: 0x4 0x3e 0x1 LOGICAL UNIT FAILURE

For more information about SCSI sense codes in vSphere, see Interpreting SCSI sense codes (289902).

Note: Some iSCSI arrays map LUN-to-Target as a one-to-one relationship. That is, there is only ever a single LUN per Target. In this case, the iSCSI arrays do not return the appropriate SCSI sense code, so PDL on these arrays types cannot be detected. However, in ESXi 5.1, enhancements have been made and now the iSCSI initiator attempts to re-login to the target after a dropped session. If the device is not accessible, the storage system rejects the host’s effort to access the storage. Depending on the response from the array, the host can now mark the device as PDL.

All-Paths-Down (APD)

If PDL SCSI sense codes are not returned from a device (when unable to contact the storage array, or with a storage array that does not return the supported PDL SCSI codes), then the device is in an All-Paths-Down (APD) state, and the ESXi host continues to send I/O requests until the host receives a response.

As the ESXi host is not able to determine if the device loss is permanent (PDL) or transient (APD), it indefinitely retries SCSI I/O, including:

  • Userworld I/O (hostd management agent)
  • Virtual machine guest I/O

    Note: If an I/O request is issued from a guest, the operating system should timeout and abort the I/O.

Due to the nature of an APD situation, there is no clean way to recover.

  • The APD situation needs to be resolved at the storage array/fabric layer to restore connectivity to the host.
  • All affected ESXi hosts may require a reboot to remove any residual references to the affected devices that are in an APD state.

Note: Performing a vMotion migration of unaffected virtual machines is not possible, as the management agents may be affected by the APD condition, and the ESXi host may become unmanaged. As a result, a reboot of an affected ESXi host forces an outage to all non-affected virtual machines on that host.

Planned versus unplanned PDL

A planned PDL occurs when there is an intent to remove a device presented to the ESXi host. The datastore must first be unmounted, then the device detached before the storage device can be unpresented at the storage array. For more information on how to correctly unpresent a LUN in ESXi 5.x, see Unmounting a LUN or detaching a datastore/storage device from multiple ESXi 5.x hosts (2004605).

An unplanned PDL occurs when the storage device is unexpectedly unpresented from the storage array without the unmount and detach being executed on the ESXi host.

In ESXi 5.5, VMware provides a feature called Auto-remove for automatic removal of devices during an unplanned PDL. For more information, see PDL AutoRemove feature in vSphere 5.5 (2059622).

To clean up an unplanned PDL:

  1. All running virtual machines from the datastore must be powered off and unregistered from the vCenter Server.
  2. From the vSphere Client, go to the Configuration tab of the ESXi host, and click Storage.
  3. Right-click the datastore being removed, and click Unmount.

    The Confirm Datastore Unmount window displays. When the prerequisite criteria have been passed, the OK button appears.

    If you see this error when unmounting the LUN:

    Call datastore refresh for object <name_of_LUN> on vCenter server <name_of_vCenter> failed

    You may have a snapshot LUN presented. To resolve this issue, remove that snapshot LUN on the array side.

  4. Perform a rescan on all of the ESXi hosts that had visibility to the LUN.

    Note: If there are active references to the device or pending I/O, the ESXi host still lists the device after the rescan. Check for virtual machines, templates, ISO images, floppy images, and raw device mappings which may still have an active reference to the device or datastore.

  5. If the LUN is still being used and available again, go to each host, right-click the LUN, and click Mount.

    Note: One possible cause for an unplanned PDL is that the LUN ran out space causing it to become inaccessible.

See Also

(VMware Tutorial) Step by Step Installation for VMware vRealize Automation Distributed 6.1 (Part 1)

I would like to write a series on installation and configuration of VMware VRealize Automation (previously it was called vCloud Automation Center). I am writing these blog series based on my experience implementing it in one of big company, and they need a very big scalability infrastructure for their Cloud Management Platform. (> 50.000 users).

So, these are the steps to install, deploy & configure VRA 6.1 :

Step by Step Installation for VMware vRealize Automation Distributed 6.1 :

  1. Install & Configure F5 LTM and F5 GTM Load Balancer, DONE
  2. Create & Configure SAN Trusted Certificate (key, pem, pfx) from CA Server, DONE
  3. Install & Configure VMware Identity Appliance + certificate, DONE
  4. Install & Configure VCAC Appliance Primary + certificate, DONE
  5. Install & Configure Primary PostgreSQL. DONE
  6. Change DB for VCAC Appliance Primary to Stand Alone, DONE
  7. Install & Configure VCAC Appliance Secondary (Cluster), DONE
  8. Install & Configure VCAC Appliance Virtual Server (LB), DONE
  9. Install & Configure Secondary PostgreSQL (Cluster), DONE
  10. Test Cluster Functionality to VCAC from Load Balancer, DONE
  11. Test Cluster Functionality to PostgreSQL Database, DONE
  1. Configure vCenter and SQL Server to Join Domain,  DONE
  2. Install & Configure IAAS Web Primary + certificate, DONE
  3. Install & Configure IAAS Web Secondary + certificate, DONE
  4. Install & Configure IAAS Web Virtual Server (LB), DONE
  5. Install & Configure IAAS Mgr & DEM Orch Primary + certificate, DONE
  6. Install & Configure IAAS Mgr & DEM Orch Secondary + certificate, DONE
  7. Install & Configure IAAS Mgr & DEM Orch Virtual Server (LB), DONE
  8. Install & Configure DEM Worker @1st Site, DONE
  9. Install & Configure IAAS Agent @1st Site, DONE
  10. Install & Configure DEM Worker @2nd Site,  DONE
  11. Install & Configure IAAS Agent @2nd Site, DONE
  12. Install & Configure DEM Worker @3rd Site, DONE
  13. Install & Configure IAAS Agent @3rd Site, DONE
  1. Install & Configure VCO Server 1, DONE
  2. Install & Configure VCO Server 2, DONE
  3. Install & Configure VCO Virtual Server (LB), DONE
  1. Install & Configure ITBM, DONE


Location of log files for VMware products

To determine the default log locations for VMware products, see the most relevant document.
vSphere Suite
vCenter Server (formerly VirtualCenter Server):
vSphere Data Recovery:
vSphere Storage Appliance:
Site Recovery Manager
vCloud Director:
vShield/vCloud Networking and Security (vCNS):
VMware vCloud Automation Center 6.x:
vCenter Orchestrator:
Desktop Computing
View and Horizon View:
Horizon Mirage (formerly Mirage):

VMware Workstation:

Review: Puppet vs. Chef vs. Ansible vs. Salt

Once again, I am taking this article from another website ( It is a very good article that I would like to remember. So, that is the reason why I re-post it again in my blog.

Review: Puppet vs. Chef vs. Ansible vs. Salt

The leading configuration management and orchestration tools take different paths to server automation


The proliferation of virtualization coupled with the increasing power of industry-standard servers and the availability of cloud computing has led to a significant uptick in the number of servers that need to be managed within and without an organization. Where we once made do with racks of physical servers that we could access in the data center down the hall, we now have to manage many more servers that could be spread all over the globe.

This is where data center orchestration and configuration management tools come into play. In many cases, we’re managing groups of identical servers, running identical applications and services. They’re deployed on virtualization frameworks within the organization, or they’re running as cloud or hosted instances in remote data centers. In some cases, we may be talking about large installations that exist only to support very large applications or large installations that support myriad smaller services. In either case, the ability to wave a wand and cause them all to bend to the will of the admin cannot be discounted. It’s the only way to manage these large and growing infrastructures.

[ Read the individual reviews: Puppet • Chef • Ansible • Salt | Puppet or Chef: The configuration management dilemma | Subscribe to InfoWorld’s Data Center newsletter to stay on top of the latest developments. ]

PuppetChefAnsible, and Salt were all built with that very goal in mind: to make it much easier to configure and maintain dozens, hundreds, or even thousands of servers. That’s not to say that smaller shops won’t benefit from these tools, as automation and orchestration generally make life easier in an infrastructure of any size.

I looked at each of these four tools in depth, explored their design and function, and determined that, while some scored higher than others, there’s a place for each to fit in, depending on the goals of the deployment. Here, I summarize my findings.

Puppet Enterprise
Puppet arguably enjoys the biggest mind share of the four. It’s the most complete in terms of available actions, modules, and user interfaces. Puppet represents the whole picture of data center orchestration, encompassing just about every operating system and offering deep tools for the main OSes. Initial setup is relatively simple, requiring the installation of a master server and client agents on each system that is to be managed.

From there, the CLI (command-line interface) is straightforward, allowing module downloads and installation via the puppet command. Then, changes to the configuration files are required to tailor the module for the required task, and the clients that should receive the instructions will do so when they check in with the master or via a push that will trigger the modifications immediately.

There are also modules that can provision and configure cloud server instances and virtual server instances. All modules and configurations are built with a Puppet-specific language based on Ruby, or Ruby itself, and thus will require programmatic expertise in addition to system administration skills.


Test Center Scorecard
20% 20% 20% 20% 10% 10%
AnsibleWorks Ansible 1.3 9 7 8 8 9 9
20% 20% 20% 20% 10% 10%
Enterprise Chef 11.4 9 8 7 9 8 9
20% 20% 20% 20% 10% 10%
Puppet Enterprise 3.0 9 9 9 9 9 9
20% 20% 20% 20% 10% 10%
SaltStack Enterprise 0.17.0 9 8 9 9 9 9

Puppet Enterprise has the most complete Web UI of the bunch, allowing for real-time control of managed nodes using prebuilt modules and cookbooks present on the master servers. The Web UI works well for management, but does not allow for much configuration of modules. The reporting tools are well developed, providing deep details on how agents are behaving and what changes have been made.

Enterprise Chef
Chef is similar to Puppet in terms of overall concept, in that there’s a master server and agents installed on managed nodes, but it differs in actual deployment. In addition to a master server, a Chef installation also requires a workstation to control the master. The agents can be installed from the workstation using the knife tool that uses SSH for deployment, easing the installation burden. Thereafter, managed nodes authenticate with the master through the use of certificates.

Continue reading Review: Puppet vs. Chef vs. Ansible vs. Salt

VMware TCO / ROI Calculator User’s Guide

You can directly use the Tool in this link = http://

You can read the detail description of TCO in here =


This is some simple User Guide on How to use the Tool :

The VMware TCO Calculator was developed jointly by VMware, Inc. and ex-Gartner ROI / TCO experts from Alinean, Inc. to provide a Total Cost of Ownership (TCO) and Return on Investment (ROI) analysis for implementing VMware solutions to virtualize your IT environment including datacenter server infrastructure, testing/development labs and desktops.

You can quickly assess potential cost savings by completing five easy steps:

Step 1: Fill out a Simple Survey Questionnaire

Answer a few questions about your company (such as the type of industry you are in, and location) and which of the VMware solution sets you are most interested in:
1. Data Center Server Consolidation Cost Savings (Using VMware Infrastructure 3)
2. Virtual Lab Automation Benefits (Using VMware Lab Manager)
3. Desktop Control and Manageability Cost Savings (Using VMware Virtual Desktop Infrastructure VDI)

For each selected solution area of interest, you will be asked five to ten additional questions  about your existing assets such as the number of servers or desktops you intend to virtualize,  and about cost reduction opportunities such as current server management, management  activities, storage and other metrics.

Default metrics are provided for all of the questions based on Alinean research regarding your specified industry and location. These defaults can be reviewed and adjusted to best match your own unique metrics. This is the only information that is necessary to get a quick estimate of potential cost savings and return on investment (ROI)!

Step 2: Customize Assumptions

The tool uses over 200 additional metrics to help calculate a credible and achievable costbenefit / ROI analysis. Each of the 200 metrics is set using default assumptions based on the metrics you provided on the questionnaire regarding your industry, location, assets and current cost opportunities, and using industry average and third party research. All of these values are preset using this research, but can be easily reviewed and refined by clicking on the “View/Edit Default Assumptions” link on the bottom right corner of each solution set on the Questionnaire page. You can then review each default assumption and make adjustments to
precisely reflect your current environment and actual costs as needed. For a quick analysis, you can skip this step, revisiting the default assumptions for refinement later.

Step 3: Review Total Cost Savings and Return on Investment (ROI)

Click on the “Next” button to see your customized cost savings, comparing your current (As Is) total cost of ownership (TCO) over the next three years (managing a non-virtualized / business as usual environment), and the cost savings and business benefits estimated for a virtualized VMware environment. Key metric and financial improvements are summarized at the top, while specific details for each solution are provided in the tables, graphs and charts. For each selected VMware solution, you can click on the solution name in the table or the tab to view cost savings / benefit, investment and ROI details for VMware Infrastructure 3, VMware Lab Manager and VDI independently.  Continue reading VMware TCO / ROI Calculator User’s Guide

Step by Step for vCenter Upgrade from 5.1 to 5.5

I am taking this Tutorial from VMware Communitiies (VMTN). This is a very common questions to ask, so I re-post it again in this blog.

Make sure below 6 tasks has been completed before starting of vCenter Upgrade.

  1. 2 hours before the upgrade disable all Schedule VM backups for vCenter or 3rd Party Tools
  2. Once backup disabled request Database Team to backup below databases 30 mins before the vCenter upgrade –
    1. vCenter Server database
    2. SRM database
  3. On vCenter, make a copy of the SSL certificates, copy them backup folder
  4. Backup Inventory Service database. Follow below procedure
  • On the source machine, open the command prompt in the vCenter Server and change the directory to vCenter_Server_installation_directoryInfrastructureInventory Servicescripts.
  • Run the following command at the prompt to back up the Inventory Service database.
  • backup.bat -file gdciventoryvcenter.bak
  • When the backup operation finishes, the message Backup completed successfully appears, copy the file to backup folder
  1. Backup the SSO configuration
    1. Click on start/programs/vmware
    2. Select Generate vCenter Single Signon Backup bundle, this creates a zip file on the desktop
    3. Select Generate vCenter single Signon log bundle
    4. Copy these files to backup folder
  2. 5 minutes prior to upgrade of vCenter

    Create a snapshot of vCenter.

    ********** UPGRADATION **********

Once the jobs or tasks written in above completed, we will start with vCenter Server Upgrade from 5.1 to 5.5

We need to upgrade the vCenter Server in below sequence.

  1. Single Sign On – SSO
  2. vSphere Web Client
  3. vSphere Inventory Service
  4. vCenter Service
  5. vCenter Update Manager
  6. VMware Site Recovery Manager


  7. Single Sign On Upgrade:


  8. Mount the ISO and kick off the SSO installer under custom upgrade.
    1. All the required install files for all products we are upgrading are located on each VC server under “d:vCenter 5.5 and related”


Continue reading Step by Step for vCenter Upgrade from 5.1 to 5.5

Fight the FUD – Oracle Licensing and Support on VMware vSphere

In this post I will copy-paste one of the Best reading for Virtualizing Business Critical Applications from Michael Webster’s blog. This can explain that Oracle Database can be virtualized in VMware! Enjoy!

These are the source :



I keep hearing stories from Customers and Prospects where Oracle appears to be trying to deceive them for the purposes of extorting more license money from them than they are legally required to pay. I also keep hearing stories of Oracle telling them they would not be supported if they virtualized their Oracle systems on VMware vSphere. This has gone on now for far too long and it’s time to fight back and stop the FUD (Fear, Uncertainty, Doubt)!

In my opinion the best way for you to prevent this situation for your company is by knowing the right questions to ask, and by knowing what your obligations are. The aim for this article is to give you the tools to pay only what you legally owe, while making the most efficient and economic use of your licenses, and get the world class support that you are used to, even in a virtualized environment on VMware vSphere. All without sacrificing availability or performance.
I’m going to start this article by quoting Dave Welch, CTO, House of Brick – “I believe in paying every penny I owe. However, beyond that, it is my discretion to who or what I donate and in what amount. I have no patience with individuals or entities that premeditate the creation of OLSA compliance issues.  I similarly have no patience with the knowing spreading of FUD by some professionals in what could be construed as extortion of funds beyond customers’ executed contractual obligations. I will continue to vigorously promote and defend the legal rights of both software vendors and their customers even if that means I induce accelerated hair loss through rapid, frequent hat swapping.” Source Jeff Browning‘s EMC Communities article – Comments by Dave Welch of House of Brick on Oracle on VMware Licensing.

I agree with Dave on this. So I am going to show you how you can pay what you owe, while using what you pay for as efficiently and cost effectively as possible, and show you how you can still enjoy the full support you are entitled to. Without the scaremongering that sometimes accompanies discussions with Oracle Sales Reps.

For those that aren’t familiar with the term FUD, it is an acronym which stands for Fear, Uncertainty and Doubt. Something some companies and professionals seem to go to great lengths to create in the minds of customers.

FUD #1 – Oracle Licensing and Soft Partitioning
Oracle’s Server/Hardware Partitioning document outlines the different types of partitioning and how they impact licensing. Oracle may try and tell you that licensing a VMware environment will be more expensive as they don’t consider VMware Hard Partitioning. This is complete rubbish. This assertion is completely irrelevant unless you were only planning on deploying a single small database on a very small subset of a very large server. In this case you probably wouldn’t be using Enterprise Edition and may not be paying per CPU Core (Named User Plus instead). Why would you deploy such a system when you could easily purchase a server that is the right size for the job and licensed appropriately for the job? There is absolutely no requirement to run Oracle Enterprise Edition just because you are virtualizing your databases.

There is absolutely no increase in licensing costs over and above what you would have to pay for the same physical infrastructure to run your Oracle Database if you were running it in the OS without virtualization. You still have to pay what you owe, for what you use. The truth is that your costs could actually be significantly less when virtualizing on VMware vSphere as you can get more productive work done for the same amount of physical hardware, and therefore the license requirements and your costs will be significantly less. This is because you can run multiple Oracle databases on the same server and effectively share the resources, including memory, provided you take care during your design to ensure any undesirable performance impacts are avoided.  Take this image for example showing consolidating two dissimilar workloads on the same hardware (Source: VMware).

Continue reading Fight the FUD – Oracle Licensing and Support on VMware vSphere

Daftar Komprehensif mengenai Default URL, Username, dan Password di berbagai macam Produk VMware Inc.

Berikut ini adalah daftar yang sangat komprehensif mengenai default username dan password untuk berbagai macam produk dari VMware. Saya mengutipnya dari Blog Kendrick Coleman, agar tidak sering lupa jadi saya memasukkan ini di dalam blog


Horizon Application Manager




Horizon Connector



vCenter Appliance Configuration


username: root

password: vmware


vCenter Application Discovery Manager


username: root

password: 123456

default ADM management console password is 123456 and the CLI password is ChangeMe


vCenter Chargeback


username: root

password: vmware


vCenter Infrastructure Navigator:


username: root

password: Supplied during OVA deployment


vCenter Log Insight

https:// log_insight-host/

username: admin

password: password specified during initial configuration


vCenter MOB



vCenter Web Client Configuration


username: root

password: vmware


vCenter vSphere Web Client Access


username: root

password: vmware

For vSphere 5.1  = Windows default username: admin@System-Domain

For vSphere 5.1 = Linux (Virtual Appliance) default username: root@System-Domain

For vSphere 5.5 = default username: administrator@vsphere.local
Continue reading Daftar Komprehensif mengenai Default URL, Username, dan Password di berbagai macam Produk VMware Inc.

VCDX – Supporting Documentation

Berikut ini, saya mengutip resource yang sangat baik dari mengenai persiapan untuk mengambil sertifikasi VCDX. Sertifikasi tertinggi dari VMware Inc.

Once you have finished your design documents, you then have to prepare the supporting documentation.  The length of this task is very often underestimated by aspiring candidates, who either rush the job to make the submission and possibly have their application rejected due to incompleteness or miss their submission date.


List of articles in VCDX series:

  1. VCDX – Recipe for Success
  2. VCDX Study Plan – Networking
  3. VCDX Study Plan – Security
  4. VCDX Study Plan – Storage
  5. VCDX Study Plan – BC/DR
  6. VCDX Study Plan – Compute & vSphere
  7. VCDX – The Submission
  8. VCDX – The Presentation
  9. VCDX – D-Day
  10. VCDX – Think like a Panelist
  11. VCDX – I passed, now what?
  12. VCDX – Design Scenario Strategy
  13. VCDX – Troubleshooting Scenario Strategy
  14. VCDX – Mock Design Scenarios
  15. VCDX – Mock Troubleshooting Scenarios
  16. VCDX – Learn to speak “VCDXese”
  17. VCDX – How do I measure if my Customer Requirements are being met?
  18. VCDX – Logical & Physical Design Blueprints
  19. VCDX – Study Group Etiquette
  20. VCDX – Supporting Documentation

The term “Supporting Documentation” refers to the following documents/sections from the VCDX Blueprint:

  • Implementation Plan
  • Configuration Guide
  • Test Plan
  • Standard Operating Procedures

Assuming you have validated that your design meets your Customer’s Requirements, you now have to ensure that your supporting documentation will allow the design to be implemented, configured, tested and operated successfully.  This is where we separate the men from the boys, so much effort has gone into the design process, you then need to marshal your resources and push through the creation of the supporting documentation.

The strategy is very simple, create a linked list that maps from each physical design decision to the Implementation Plan, Configuration Guide, Test Plan and the SOPs.  This is summarised in the diagram below:


It is very important to maintain a unique numbering system throughout all of your documentation; this will allow you to quickly verify that all components and scenarios are covered and then collate them into a matrix to ensure that nothing is missed.  For example: supporting_documentation_template and supporting_documentation_matrix.