I used the onevcenter command to import a template for a large VM system and wanted to use linked clones. I said “y” to use linked clones during the wizard, and opted not to have a copy created (can use the existing vmdks). At this point it’s supposed to create the delta disks but it simply doesn’t. It thinks for a bit, doesn’t say anything else about creating delta disks, then spits out the Template ID indicating a success. I try to then instantiate a VM and it begins the deployment in vcenter but still fully copies all the vmdks to the same folder the template sits on but adds the -1234 vm ID to the end of the vmdk file
We are using Opennebula 5.6 (recently upgraded) on Ubuntu 16.04 with vcenter 6.7
What is doubly odd, is we have old templates that were imported before the upgrade to 5.6 that are setup to use linked clones and they are instantiating correctly against vcenter 6.5 (we are connected to two vcenters simultaneously).
Both vcenters have the same access to the same physical underlying datastores, with a unique datastore entry setup for each vcenter instance.
I’ve tried explicitly specifying the same datastore the template image lives on in the scheduler and it still doesn’t work, but the older working templates do not have an explicit datastore selected in the scheduler and still work fine.
For the moment the feature is working as expected for me, i can see the delta creation when i import a template using linked_clone option.
When you import a template without copy and with linked clone option, you should be able to see in your vsphere-client the reconfigure operation to the template so just after this (you know the ID of the new template in opennebula) the new delta-disk is available in your vCenter datastore folder.
other thing that comes to my mind is that vCenter67 is not supported by the moment, however it should work.
So it does look like the VM is reconfigured for delta disks in vcenter during the template creation. However, when I go to instantiate a VM using this template, it actually goes through the entire vmdk copy process and starts placing a full copy of the vmdk files inside the template folder with the “one-xxx” vm name prefix in it.
I have the templates configured to sort the resulting machines into folders and it works in other, non linked clone templates. It is almost like the instantiate process is ignoring the linked-clone nature of the template as well as the folder placement.
I confirmed the linked clone flag is set in the template file itself.