Main menu

VSICM55 - Slide 06-11 - NFS



Room for improvement:

Slide graphic states:

Supports NFS version 3 over TCP/IP.
Correct:

As a fellow VMware and NetApp Certified Instructor has noted, the slide graphic should be better stating:

Supports NFS version 3 over TCP.

This as opposed to default NFS transport, which is UPD. Starting with NFS version 3 it is possible to choose between UDP and TCP.

Source:

RFC 1813: NFS Version 3 Protocol Specification - Paragraph 2.3 "Transport address".

Credits:

Francesco Giuliano.


Read more...

VSICM55 - Slide 07-31 - Migrating Virtual Machines



1. Wrong:

When describing the various virtual machine migration types, the name of the last one is completely wrong. Slide notes state:

Enhanced vMotion Compatibility (EVC): Migrate a powered-on virtual machine to a new datastore and a new host.
1. Correct:

Enhanced vMotion Compatibility (EVC) is something completely different. EVC is a cluster feature that prevents vSphere vMotion migrations from failing because of incompatible CPUs.

The vMotion migration without shared storage, introduced in vSphere 5.1, was originally named Enhanced vMotion. Hence, due to the similarity between the two names, the confusion above took place.

As with vSphere 5.5, VMware has decided to rename the feature as Cross-Host vMotion Migration in the course slides and vMotion Without Shared Storage in the VMware vSphere 5.5 Documentation Center. Whichever name you want to refer to, it cannot anyway be EVC.

1. Source:

VMware vSphere 5.5 Documentation Center.



2. Wrong:

In the slide graphic, last bullet states:

A maximum of eight simultaneous vMotion, cloning, deployment, or Storage vMotion accesses to a single VMware vSphere® VMFS-5 datastore is supported.
2. Correct:

Starting with vSphere 4.1, the maximum number of simultaneous vMotion operations per datastore has been increased to 128. Additionally there is no difference, in terms of maximum concurrent operations, between a VMFS-3, a VMFS-5 or an NFS datastore. Other limits listed in the slide - cloning, deployment and Storage vMotion - are still valid as of vSphere 5.5.

2. Info:

More details about why the above limits apply to datastores and hosts can be found in the "vCenter Server and Host Management" guide, "Migrating Virtual Machines in the vSphere Web Client" chapter - "Limits on Simultaneous Migrations in the vSphere Web Client" paragraph, available in the vSphere 5.5 Documentation Center.

2. Source:

Configuration Maximums for VMware vSphere 4.1.

Configuration Maximums for VMware vSphere 5.0.

Configuration Maximums for VMware vSphere 5.1.

Configuration Maximums for VMware vSphere 5.5.



3. Wrong:

At the end of the slide notes you can read that:

With file relocation, the contents of the raw LUN mapped by the RDM are copied into a new .vmdk file at the destination. The copy operation is effectively converting a raw LUN into a virtual disk.
If you must cold-migrate a virtual machine without cloning or converting its RDMs, remove them from the configuration of the virtual machine before migrating and recreate them when migration has completed.
3. Correct:

The above statements are either incomplete or incorrect. The described Storage vMotion behavior was a limitation when migrating RDMs in vSphere 4.x, yet in vSphere 5.x it has been improved.
Cormac Hogan - a Senior Storage Architect in the Integration Engineering team which is part of VMware R&D - has further clarified RDM behavior during Storage vMotion operations.

  • VM with Physical (Pass-Thru) RDMs (Powered On – Storage vMotion):
    • If I try to change the format to thin or thick, then no Storage vMotion allowed.
    • If I chose not to do any conversion, only the pRDM mapping file is moved from the source VMFS datastore to the destination VMFS datastore – the data stays on the original LUN.
  • VM with Virtual (non Pass-Thru) RDMs (Power On – Storage vMotion):
    • On a migrate, if I chose to covert the format in the advanced view, the vRDM is converted to a VMDK on the destination VMFS datastore.
    • If I chose not to do any conversion, only the vRDM mapping file is moved from the source VMFS datastore to the destination VMFS datastore – the data stays on the original LUN (same behavior as pRDM).
  • VM with Physical (Pass-Thru) RDMs (Powered Off – Cold Migration):
    • On a migrate, if I chose to change the format (via the advanced view), the pRDM is converted to a VMDK on the destination VMFS datastore.
    • If I chose not to do any conversion, only the pRDM mapping file is moved from the source VMFS datastore to the destination VMFS datastore – the data stays on the original LUN.
  • VM with Virtual (non Pass-Thru) RDMs (Power Off – Cold Migration):
    • On a migrate, if I chose to covert the format in the advanced view, the vRDM is converted to a VMDK on the destination VMFS datastore.
    • If I chose not to do any conversion, only the vRDM mapping file is moved from the source VMFS datastore to the destination VMFS datastore – the data stays on the original LUN (same behaviour as pRDM).
3. Source:

VMware vSphere Blog.


Read more...

VSICM55 - Slide 06-34 - Viewing IP Storage Information



Wrong:

The slide notes ordered list instructing you how to view datastores information is either messed up between steps required in the vSphere Client and those in the vSphere Web Client or - in some cases - completely wrong:

  1. Select an ESXi host.
  2. Click the Storage link in the ESXi host’s Configuration tab.
        The Storage link lists all the datastores that the host can access.
  3. In the Datastores pane, right-click the datastore and select Browse Datastore.
        The Datastore Browser displays the contents of the datastore.
Correct:

As the "VMware vSphere: Install, Configure, Manage [V5.5]" course has transitioned to the vSphere Web Client GUI, the above list of tasks should be corrected as follows to describe the actual steps in the Web Client:

  1. Select an ESXi host.
  2. Click the Datastore link in your host Related Objects tab.
        The Datastore link lists all the datastores that the host can access.
  3. Click the Navigate to the datastore file browser link to be forwarded to the Files pane of the datastore Manage tab.
        The Datastore Browser displays the contents of the datastore.

Read more...

VSICM55 - Slide 06-33 - Configuring an NFS Datastore



Wrong:

The slide notes ordered list instructing you how to create an NFS datastore is either messed up between steps required in the vSphere Client and those in the vSphere Web Client or - in a case - completely wrong:

  1. Click the Storage link in your host’s Manage tab.
  2. Click the Add Storage link and select Network File System as the storage type.
  3. Enter the properties of your NFS datastore.
Correct:

As the "VMware vSphere: Install, Configure, Manage [V5.5]" course has transitioned to the vSphere Web Client GUI, the above list of tasks should be corrected as follows to describe the actual steps in the Web Client:

  1. Click the Datastore link in your host’s Related Objects tab.
  2. Click the Create a new datastore link and select Network File System as the storage type.
  3. Enter the properties of your NFS datastore.

Read more...

VSICM51 - 02-17 - Physical File Systems and VMware vSphere VMFS



Wrong:

The second paragraph in the slide notes state:

VMFS provides an interface to storage resources so that several storage protocols (Fibre Channel, Fibre Channel over Ethernet, iSCSI and NAS) can be used to access datastores on which virtual machines can reside.
Correct:

VMFS does not provide an interface to the NAS protocol, it is instead the NFS datastore that provides it.

Info:

VMFS datastores support SCSI compliant block access storage (Fibre Channel, Fibre Channel over Ethernet and iSCSI), whilst NFS datastores support non-SCSI compliant file access storage (NAS).

Source:

vSphere 5.1 Documentation Center.


Read more...

VSICM51 - Slide 07-31 - Migrating Virtual Machines



1. Wrong:

In the slide graphic, last bullet states:

A maximum of eight simultaneous vMotion, cloning, deployment, or Storage vMotion accesses to a single VMware vSphere® VMFS-5 datastore is supported.
1. Correct:

Starting with vSphere 4.1, the maximum number of simultaneous vMotion operations per datastore has been increased to 128. Additionally there is no difference, in terms of maximum concurrent operations, between a VMFS-3, a VMFS-5 or an NFS datastore. Other limits listed in the slide - cloning, deployment and Storage vMotion - are still valid as of vSphere 5.1.

1. Info:

More details about why the above limits apply to datastores and hosts can be found in the "vCenter Server and Host Management" guide, "Migrating Virtual Machines in the vSphere Client" chapter - "Limits on Simultaneous Migrations" paragraph, available in the vSphere 5.1 Documentation Center.

1. Source:

Configuration Maximums for VMware vSphere 4.1.

Configuration Maximums for VMware vSphere 5.0.

Configuration Maximums for VMware vSphere 5.1.



2. Wrong:

At the end of the slide notes you can read that:

With file relocation, the contents of the raw LUN mapped by the RDM are copied into a new .vmdk file at the destination. The copy operation is effectively converting a raw LUN into a virtual disk.
If you must cold-migrate a virtual machine without cloning or converting its RDMs, remove them from the configuration of the virtual machine before migrating and re-create them when migration has completed.
2. Correct:

This was a typical behavior for RDMs in vSphere 4.x, yet in vSphere 5.x it has been improved.
Cormac Hogan - a senior technical marketing architect within the Cloud Infrastructure Product Marketing group at VMware - has further clarified RDM behavior during Storage vMotion operations.

  • VM with Physical (Pass-Thru) RDMs (Powered On – Storage vMotion):
    • If I try to change the format to thin or thick, then no Storage vMotion allowed.
    • If I chose not to do any conversion, only the pRDM mapping file is moved from the source VMFS datastore to the destination VMFS datastore – the data stays on the original LUN.
  • VM with Virtual (non Pass-Thru) RDMs (Power On – Storage vMotion):
    • On a migrate, if I chose to covert the format in the advanced view, the vRDM is converted to a VMDK on the destination VMFS datastore.
    • If I chose not to do any conversion, only the vRDM mapping file is moved from the source VMFS datastore to the destination VMFS datastore – the data stays on the original LUN (same behavior as pRDM).
  • VM with Physical (Pass-Thru) RDMs (Powered Off – Cold Migration):
    • On a migrate, if I chose to change the format (via the advanced view), the pRDM is converted to a VMDK on the destination VMFS datastore.
    • If I chose not to do any conversion, only the pRDM mapping file is moved from the source VMFS datastore to the destination VMFS datastore – the data stays on the original LUN.
  • VM with Virtual (non Pass-Thru) RDMs (Power Off – Cold Migration):
    • On a migrate, if I chose to covert the format in the advanced view, the vRDM is converted to a VMDK on the destination VMFS datastore.
    • If I chose not to do any conversion, only the vRDM mapping file is moved from the source VMFS datastore to the destination VMFS datastore – the data stays on the original LUN (same behaviour as pRDM).
2. Source:

VMware vSphere Blog.


Read more...
Subscribe to this RSS feed