2

When using VMware Converter Agent on a powered on (physical or virtual) Windows system, will it sent over the network all the disk blocks or only those actually in use by the NTFS filesystem?

I am trying to set up the conversion and it is possible to change partition size on the destination VM. When doing so, Converter pops up an alert saying it has to use File-level conversion - that's fine and expected - but also that file level conversion is slower than block level conversion - and that's where I don't understand.

When you have significant free space on the volume I expect file level conversion to be much faster than block level. But maybe VMware Converter is able to do a block level conversion transferring only the blocks actually in use?

HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
Luke404
  • 5,708
  • 3
  • 44
  • 58

1 Answers1

0

This behavior is determined by your settings for the destination disk.

If the destination disk is a thin-provisioned disk, no. If the destination disk is a thick-provisioned disk, yes.

General

If you try to convert a source physical or virtual machine to a managed destination by using thick provisioned disks with large empty spaces on them, the conversion task might fail If you try to perform a disk-based cloning of a physical or virtual machine to a managed destination by using thick provisioned disks with large empty spaces on them, the conversion task might fail with an error message Unable to clone disk source_disk on the virtual machine virtual_machine_name. The following messages appear in the log file:

 [03200 warning 'Default'] [,0] [NFC ERROR] NfcNetTcpRead: bRead: -1
 [03200 warning 'Default'] [,0] [NFC ERROR] NfcNet_Recv: requested 264, recevied only 0 bytes
 [03200 warning 'Default'] [,0] [NFC ERROR] NfcFile_Stream: Failed to get message from source
 [03200 warning 'Default'] [,0] [NFC ERROR] NFC_NETWORK_ERROR

The destination ESX server must return an acknowledgement after each processed NFC write request. If the source sends a large block of zeroes that must be written it might take a long time for the ESX to return the acknowledgement. Thus, the Converter assumes that the operation has timed out and closes the connection, no matter that the ESX server is still writing to the target disk.

Workaround: Change the destination disk type to thin.

And, a link to the user guide for Converter 5.5, if you want to read more about it.

HopelessN00b
  • 53,385
  • 32
  • 133
  • 208