Create Thin Provisioned VPG ?

Since you mention a VASA provider on your recovery hosts, the problem could be that vVols is configured on your recovery hosts and we don’t support vVols.

Amy Mitchell

Zerto Platform Product Manager

Hi ,

I had the same problem and upon scratching my head i found that thought we change “default data-store, journal data-store ” to “thick provisioned” datastore and proceed with vpg creation it still has some lock deep inside.

Since I don’t have PROD site access, I took a small 40gb vm(VPG) and migrated it to “Thick”  both :recovery, journal datastore.Now the vpg is completely in ‘thick’ datastore

Now I added the Vm which is 7TB thick  to this VPG and since the defaults are pointing to thick the VPG creation went successful.

The good point to note is : we can then point other vm’s which are ‘thin’ to this same VPG.

The problem/bug is only when default datastore is thin and we add ‘thick’  vm’s to it not the viceversa.

Hope this clears.

Regards,

Renga

I hit the same issue on Netapp storage (thick is not an option).  You can specify thin provisioned disks to add a VM if you add the volume array.  The problem is you have to get the SCSI ID for each disk, and if you are trying to add the VM into Zerto, those values are not available from Zerto.  Zerto as far as I can tell only has volume info for VMs already in Zerto.  I got around this by using the vmware powercli and getting the disks that way, then I was able to specify thin (or not) for each disk.  JSON ended up looking like this:

{
“VmIdentifier”: “0a3ee64c-44bc-4a6a-a335-629695fcc1da.vm-268”,
“Volumes”: [
{
“Datastore”: {
“DatastoreClusterIdentifier”: null,
“DatastoreIdentifier”: “16a52ff7-46ff-461e-aa23-93816a76c197.datastore-203”,
“IsThin”: true
},
“VolumeIdentifier”: “scsi:0:0”
},
{
“Datastore”: {
“DatastoreClusterIdentifier”: null,
“DatastoreIdentifier”: “16a52ff7-46ff-461e-aa23-93816a76c197.datastore-203”,
“IsThin”: true
},
“VolumeIdentifier”: “scsi:0:1”
},
{
“Datastore”: {
“DatastoreClusterIdentifier”: null,
“DatastoreIdentifier”: “16a52ff7-46ff-461e-aa23-93816a76c197.datastore-203”,
“IsThin”: true
},
“VolumeIdentifier”: “scsi:0:2”
},
{
“Datastore”: {
“DatastoreClusterIdentifier”: null,
“DatastoreIdentifier”: “16a52ff7-46ff-461e-aa23-93816a76c197.datastore-203”,
“IsThin”: true
},
“VolumeIdentifier”: “scsi:0:3”
}
] }

Do you have a copy of your code that does this?  I have the same issue with Thin provisioning with my powershell api.

This one took me months to solve.  When creating a VPG with the API, you first create a VPG Settings object (which I’ll call “object”), that has all your VPG settings and the VMs you want to add.  After you create this object, you then “commit” it start the VPG create.  Before you do that commit, you can still access and edit the settings within the object.  You can recall that object, which now has all the VM settings, and iterate through each volume of each VM to set the “isThin” to true.  It’s a giant system of nested foreach loops, but it works.

TLDR:

create object with VMs

$vpgSettingsId = recall object into a new variable

foreach($vmID in $vmIDList){

$volumeList = Invoke-RestMethod “htts://…/v1/vpgsettings/$vpgSettingsID/vms/$vmID/volumes” GET

foreach($volume in $volumeList){

$volumeInfo = Invoke-RestMethod “https://…/v1/vpgsettings/$vpgSettingsID/vms/$vmID/volumes/$volume.VolumeIdentifier” GET

$volumeInfo.Datastore.IsThin = $true

$volumeJson = $volumeInfo | ConvertTo-Json

Invoke-RestMethod “https://…/v1/vpgsettings/$vpgSettingsID/vms/$vmID/volumes/$volume.VolumeIdentifier” PUT -Body $volumeJson

}

}

commit vpgSettingsobject