Translate

Total Pageviews

My YouTube Channel

Friday, 2 January 2015

VMware vSphere “I moved it” or “I copied it” – What’s the difference in these Options?


When you copy or move the data store location of an existing VM running on VMware vSphere you will be presented with a message box (as seen below) in the vCenter Client asking if your VM has either been ‘moved’ or ‘copied’. As you can see the message box also mentions “msg.uuid.altered: This virtual machine may have been moved or copied”, but what does this actually mean?


What is a VM’s UUID?

Firstly, it is important to have an understanding of what a ‘UUID’ (universally unique identifier) is. As the name suggests the UUID is a ‘identifier’ (128 bit integer) which is ‘unique’ to that VM, and effectively gives it a digital fingerprint to differentiate it from other VMs.

The UUID is automatically generated when a VM is first powered on or moved, with the UUID value being based on the physical host’s identifier and also the path to the VM’s configuration (vmx) file. Within this configuration file the UUID value is stored in two places:
  • uuid.bios
  • uuid.location (hash based on the current path of the VM)

For example: uuid.bios = "56 4d 5e 58 66 f5 2d 04-03 31 0a bd 6f a7 19 88"

The UUID is also stored in the SMBIOS system information (ie: the BIOS of the VM) descriptor. When the VM is started or moved the location UUID (ie: uuid.location) which is hashed from the VM’s data store path is compared to the UUID location hash which already exists in the configuration file. At this point if the new and existing location UUID value differs then ESX knows that the VM is now running from a different data store location and will present the ‘Virtual Machine Message’ in figure 1 above.

We saw in the message above provided by ESX informing that the UUID has in someway been altered but why does this really matter? The answer to this you’ll be pleased to know is quite simple. A VM’s unique UUID is used to generate other unique values used by the VM such as the unique MAC (media access control) address of the network card(s). For example if you had multiple copies of the same VM/Guest OS running in your vSphere environment all with the same (ie: non-unique) network MAC address you will likely receive duplicate MAC address error messages within the guest OS which can cause a number of issues.

Another potential point to be mindful of is that some software licensing can be linked to a MAC address of a guest OS’s network card. This includes software such as Microsoft Windows where changing the MAC address and some other key hardware components (eg: moving from an Intel based ESX host to a AMD based ESX host) can mean you have to re-activate the software again. The changing of a VM’s MAC address will occur when you select “I copied it”, the next couple of sections will go into more detail on what exactly is altered.
Should I Select “I Moved It” or “I Copied It”?
So what is the difference between selecting “I_moved it” or “I_copied it”? The easiest way to demonstrate the differences is by viewing the configuration file (vmx) for the VM before and after the two different options have been selected. 

“I Moved It”

By indicating that you had moved the VM (instead of copying it) the only UUID change that is made to the configuration file is to the ‘uuid.location’ setting, which as you’d expect indicates a change of location for the VM. The ‘uuid.bios’ and the existing generated network MAC address remains that same.

You will also notice that the CPUID settings have also changed which is also the case for when you indicate that the VM was copied.

The “I Moved It” option should be used when ‘moving’ the location of where a VM resides and a copy of the VM has not been made.
  
“I Copied It”

When you select that the VM has been copied then there a few more changes that are made to the VM’s configuration file when compared to just moving it. These changes are to the ‘uuid.bios’, ‘uuid.location’ and as a result of these changes a newly generated network MAC address (ethernet.generatedaddress).

The “I Copied It” option should be used when you’ve made, and intend to run, more than one copy of the VM in your vSphere environment.

To summarise, here is a table which outlines the changes that are made when either the “I Moved It” or “I Copied It” are selected

As you can see it is worth spending the time to understand the changes which will be made when presented with the “I moved it” or “I copied it” options as it can impact (eg: software re-activation) the guest OS of the VMware vSphere VM.

I hope this helps clarify this small aspect of VMware vSphere administration which can sometimes be an area of confusion.

Source:-
http://techhead.co/vmware-esx-i-moved-it-or-i-copied-it-whats-the-difference/ 

Authentication denied. Direct console access has been disabled by the administrator for hostname

When you log in as root directly to DCUI, you see this message:
Authentication denied. Direct console access has been disabled by the administrator for hostname.

You cannot even use vSphere Client, vSphere Web Client to access the ESXi host. But you can use SSH only to connect the ESXi





Then how to resolve this Issue:-

1. Restart all the services of ESXi (via SSH)

./sbin/services.sh restart

2. Then Reboot the ESXi

Increasing the Thick Eagerzeroed Disk Size


As i increased the disk size of thick eager zeroed and as soon as it is increased it gets converted automatically in to thick lazy zeroed. Now this is known behavior of If you increased the size of eager zeroed disk using the UI, this is the normal behavior... to increase the size of a eager zeroed disk and maintain this format for the new added space, you will need to use the CLI.

For this Use ESXi Shell or SSH and then Open the VM Directory and execute the command in this format.

# vmkfstools -X 6G -d eagerzeroedthick vm.vmdk

Text given in Red color : You can use values here as per your configuration requirement. 

To refresh the provisioned disk space value there are two methods:
 
First Method:- Remove the VM from Inventory > Then Add to Inventory
  1. Open and login to vSphere client.
  2. Power off the virtual machine.
  3. Right-click and select Remove from Inventory.
  4. Click Configuration > Storage > Browse the datastore
  5. Locate the .vmx file, Right-click and select Add to Inventory.
  6. After the Virtual machine is successfully added to the Inventory, the correct value will be displayed.
Second Method:- Reload the .vmx File
 
You can keep your VM in Power On State to Reload the .vmx file
 
Obtain the Inventory ID (Vmid) for the virtual machine using this command:

# vim-cmd vmsvc/getallvms
  
Reload the .vmx file using this command: 
 
# vim-cmd vmsvc/reload Vmid
 
 
 Reference KB's:-
 

Identifying virtual disks pointing to Raw Device Mappings (RDMs) (1005937)

Purpose

This article provides advanced users with a method to list all of the virtual disks pointing to a physical disk (Raw Device Mapping, or RDM) from PowerCLI and from the ESX/ESXi host console.
This method does not explicitly state the virtual machine which is using the raw device mapping pointer file, though it can be inferred from the directory name. It will instead provide the LUN to RDM mapping. To obtain a list of registered virtual machines and the associated RDMs, see Identifying virtual machines with Raw Device Mappings (RDMs) using PowerCLI (2001823).
Note: This method is generally time-consuming, as all Datastores must be searched iteratively for VMDK files. If those VMDK files are locked, such as by a running virtual machine, inquiring for the target device fails. In this case, it is better to search for registered virtual machines.

Resolution

To list all virtual disks pointing to an RDM device using PowerCLI:

This operation is generally time-consuming, as PowerCLI must iteratively inquire about the disk type of every VMDK file on the remote hosts. Checking locked files adds a few seconds of delay. The device which the RDM points to cannot be determined without a virtual machine attached.
  1. Open the vSphere PowerCLI command-line. For more information, see the vSphere PowerCLI Documentation.
  2. Run the command:

    Get-Datastore | Get-HardDisk -DiskType "RawPhysical","RawVirtual" | Select "Filename","CapacityKB" | fl

    Example output:

    Filename    : [DatastoreName] DirectoryName/virtualrdm.vmdk
    CapacityKB  : 5760

    Note: The mapped device is not exposed, only the existence of the RDM. To determine the target device which it is mapped to, add this virtual disk to a virtual machine or use the console method.

To list all virtual disks pointing to an RDM device using the local console:

This operation is generally quick, as there is no overhead of network communication.
  1. Open a console to the ESX or ESXi host. For more information, see Unable to connect to an ESX host using Secure Shell (SSH) (1003807) or Using Tech Support Mode in ESXi 4.1 (1017910).
  2. Run the command:

    #find /vmfs/volumes/ -type f -name '*.vmdk' -size -1024k -exec grep -l '^createType=.*RawDeviceMap' {} \; > /tmp/rdmsluns.txt

    #for i in `cat /tmp/rdmsluns.txt`; do vmkfstools -q $i; done


    Example output:

    • Virtual Mode RDM:

      Disk /vmfs/volumes/.../virtualrdm.vmdk is a Non-passthrough Raw Device Mapping
      Maps to: vml.02000000006006048000019030091953303030313253594d4d4554
    • Physical Mode RDM:

      Disk /vmfs/volumes/.../physicalrdm.vmdk is a Passthrough Raw Device Mapping
      Maps to: vml.02000000006006048000019030091953303030313253594d4d4554

    Note: For more information on identifying the mapped device, see Identifying disks when working with VMware ESX/ESXi (1014953).

Additional Information

Note: This process may be useful before engaging in a resignaturing process. For more information about resignaturing, see Resignaturing VMFS3 volumes on VMware ESX 3.x via the VMware Infrastructure Client (9453805).
 
To query a specific virtual disk pointing to an RDM device using the local console, run the command:
 # vmkfstools –q <path_to_rdm_vmdk>
 
For example:
# vmkfstools –q  /vmfs/volumes/mydatastore/myvm/physicalrdm.vmdk
Disk /vmfs/volumes/.../physicalrdm.vmdk is a Passthrough Raw Device Mapping
Maps to: vml.02000000006006048000019030091953303030313253594d4d4554
 
Source KB:-
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1005937&src=vmw_so_vex_ragga_1012