When attempting to copy VMDK files from running virtual machines on ESX 3.5 U3, you'll encounter the frustrating "Device or resource busy" error. This happens because VMware locks the virtual disk files when VMs are powered on to prevent data corruption. While proper procedure demands VM shutdowns for storage migration, test scenarios like evaluating NetApp deduplication may not require production-level data integrity.

For non-production testing purposes, we have several technical approaches:

# Method 1: Using dd for raw disk copying
dd if=/vmfs/volumes/source_datastore/VM_NAME/disk1.vmdk \
   of=/vmfs/volumes/target_datastore/VM_NAME/disk1.vmdk \
   bs=1M conv=noerror,sync

# Method 2: vmkfstools cloning (works for some locked files)
vmkfstools -i /vmfs/volumes/source_datastore/VM_NAME/disk1.vmdk \
           /vmfs/volumes/target_datastore/VM_NAME/disk1.vmdk \
           -d thin

• These methods may produce inconsistent copies - acceptable for deduplication testing but unsuitable for production use
• For Windows VMs, the copied disks might show filesystem errors if mounted
• ESX 3.5's locking mechanism is more restrictive than newer versions
• Performance impact scales with disk size - schedule during low-usage periods

If available in your environment, Storage VMotion provides the cleanest solution:

# Requires Enterprise Plus licensing
vmotion -t storage -h esx_hostname VM_NAME

For scripting multiple VM migrations, consider:

for VM in $(esxcli vm process list | grep "Display Name" | awk '{print $3}')
do
   vmkfstools -i /vmfs/volumes/src/$VM/$VM.vmdk \
              /vmfs/volumes/dst/$VM/$VM.vmdk
done

When working with VMware ESX 3.5 U3 environments, attempting to copy VMDK files from running virtual machines triggers file locking mechanisms that prevent standard copy operations. The typical error looks like:

cp: cannot open '...vmdk' for reading: Device or resource busy

Since conventional file copy tools fail due to VMWare's locking mechanism, we need specialized approaches that work at the disk level rather than filesystem level.

Method 1: Using dd for Raw Disk Copy

This creates a block-level copy while bypassing filesystem locks:

dd if=/vmfs/volumes/original_datastore/VM_name/disk.vmdk \
   of=/vmfs/volumes/new_datastore/VM_name/disk.vmdk \
   bs=1M conv=noerror,sync

Method 2: VMware-specific Tools

The vmkfstools utility can create clones while handling VMware-specific locking:

vmkfstools -i /vmfs/volumes/original_datastore/VM_name/disk.vmdk \
           /vmfs/volumes/new_datastore/VM_name/disk_clone.vmdk

For Windows-based VMs, additional considerations apply:

# First create a snapshot to ensure consistency
vim-cmd vmsvc/snapshot.create [VMID] "Temp snapshot for copy"

# Then clone the base disk
vmkfstools -i /vmfs/volumes/datastore1/VM/disk.vmdk \
           /vmfs/volumes/datastore2/VM/disk.vmdk \
           -d thin

When copying large VMDKs from running VMs:

• Use bs=8M or higher with dd for better throughput
• Schedule during low-activity periods
• Monitor ESX host performance with esxtop

After completion, verify the new VMDKs:

vmkfstools -v /vmfs/volumes/new_datastore/VM_name/disk.vmdk