Replication Task Ignores Provisioning Mode
We have several replication tasks that are ignoring their provisioning mode.
Some of the replicated VMs use thick provisioning, some use thin.
All replication tasks are set to use thin provisioning.
The replicas are actually stored as thick provisioned, eager zeroed.
This causes a lot of unnecessary disk usage.
I've tried completely deleting the replicas and the associated test_meta.info files.
I've tried editing the task and changing the provisioning mode to thick and then changing it back to thin.
But every time a replication task completes the provisioning mode used is thick provisioned, eager zeroed.
I've even tried zero-wiping all free space in a VM, shrinking the partition down to leave 40 GB of unpartitioned space, and then running vmkfstools --punchzero VM.vmdk to shrink the actual file on the datastore.
On a 200 GB thin provisioned VM, 140 GB is used and the guest OS sees a 160 GB partition and 40 GB unpartitioned space. The actual virtual disk file is 140 GB. When editing the replication task, the estimated space required is 140 GB. The task is set to use thin provisioning. The replica is created as thick provisioned, eager zeroed, taking up 200 GB of space.
All the logs are normal, and there's no mention of the provisioning mode at all.
The only error in the logs is the CBT failure when I run the replica job for the first time (because there's no replica creation time to track changes against). On the second and third run, CBT works fine.
Any ideas?
Another issue I ran into is the following:
If your Task Name has an ampersand (&) in it, and you click on the ""Succeeded", "Warning", or "Failed" link in the task view, the log view won't load the logs for that task. The search field is populated with the task name but with the & and everything before it.
You can manually use the & in the search field on the log page, and it works, but when you click the link from a task it is dropped and the log page is blank until you manually run another search.
To reproduce this error:
Create a task named "A & B".
Run the task.
When the task has completed, click on the "Last result" link (Succeeded, Warning, or Failed).
The Logs page will show "A " in the "Task name" field, and the list of log entries will be blank.
Workaround:
You can manually search for "A & B" and the logs will display as expected.

- Anmelden, um Kommentare verfassen zu können

I did the following:
Power off VM
Edit Settings, Options, Advanced - General, Configuration Parameters
Set ctkEnabled to false
Set all scsix:y.ctkEnabled to false
Delete all -ctk files from datastore
Power on VM
Power off VM
Edit Settings, Options, Advanced - General, Configuration Parameters
Set ctkEnabled to true
Set all scsix:y.ctkEnabled to true
Power on VM
Delete existing replica from within Acronis
Run replication task
It's currently running, but it's already gotten past the CBT steps and there were no errors (CBT is enabled, CBT is used). I'll report back after it finishes.
The use in the thread you linked reported having to edit the VMX file manually on ESXI 5.5 to make the ctkEnabled=false to stick.
I didn't have to do that, but we're still on ESXi 5.
- Anmelden, um Kommentare verfassen zu können

The disk is provisioned as thin now, but it's still taking up (almost) the full 200 GB.
Replica 200 GB Thin
Replica.vmdk size: 208,249,900.00
Replica.vmdk provisioned size: 209,715,200 KB
Original 200 GB Thin
Original.vmdk size: 148,346,900.00
Original.vmdk provisioned size: 209,715,200 KB
Is this the expected behavior?
- Anmelden, um Kommentare verfassen zu können

Hi,
This doesn't seem to be a normal behavior and I was able to reproduce it only when specifically disabled CBT option in replication task properties - in this case the replica VM contains thin disks, but the size is thick in fact and the replication log contains "Changed Block Tracking (CBT) is not used." record. You should check the replication log first of all for similar records and doublecheck the sizes (use vSphere Web Client datastore browser for this purpose - it shows the actual occupied space rather than provisioned size as it could be in case of desktop client usage).
Thank you.
--
Best regards,
Vasily
Acronis Virtualization Program Manager
- Anmelden, um Kommentare verfassen zu können

The logs say CBT is enabled and CBT is used, even on the first time the replication task is run.
Replication tasks after the first one take only a few minutes.
I'm going to try deleting the replica, the meta.info file, and the replication task, then recreating the task and running it again.
- Anmelden, um Kommentare verfassen zu können

The result is the same.
The original is thin. The datastore for the original VM shows about 150 GB used out of 200 GB provisioned.
The replica is thin. The datastore for the replica shows 200 GB used out of 200 GB provisioned.
CBT is enabled and used.
I've attached the relevant section of the logs.
Anhang | Größe |
---|---|
273513-120043.txt | 5.63 KB |
- Anmelden, um Kommentare verfassen zu können

Hi,
Thank you for the details. In this case it makes sense to contact our support team for further assistance with the issue. Please add a reference to this thread to your request along with some screen shots illustrating the issue (showing the size of replica disks on datastore).
Thank you.
--
Best regards,
Vasily
Acronis Virtualization Program Manager
- Anmelden, um Kommentare verfassen zu können

Since nothing is broken, I think we'll hold off on that until we upgrade our vCenter and hosts to 5.5 (or the latest build of 5.0).
- Anmelden, um Kommentare verfassen zu können

After upgrading our vCenter Server installation (and the ESXi host) to 5.5, and updating the installation of VMware Tools on the replicated host, everything is working correctly.
- Anmelden, um Kommentare verfassen zu können