All Posts

The issue with delete instance affects only 10.4.2.2 and its described in the release notes. Updating a Runtime Defined Entity (RDE) that contains restricted fields might fail if you remove an item from an array in the entity contents ... https://docs.vmware.com/en/VMware-Cloud-Director/10.4.2.2/rn/vmware-cloud-director-10422-release-notes/index.html#Known%20Issues

Hi all, I attached the file with command output to futher investigate and, in the mean time, we will arrange by email a time slot to continue together the instance delete process. Thanks again for your support!

Dear @tandoiluca , The actual error during instance creation is related to a failure in deploying the Bring Your Own Key Appliance. The specific low-level error should be disclosed with: grep ExecutionFuture /opt/vmware/vcloud-director/logs/vcloud-container-debug.log* Also, be sure to monitor for any errors associated with the virtual machine deployment of 'vmware.bring-your-own-encryption-0.9.0-appliance (c3a61058-8a8e-4f14-9613-16a61a8b6f72).' grep "c3a61058-8a8e-4f14-9613-16a61a8b6f72" /opt/vmware/vcloud-director/logs/vcloud-container-debug.log* The second error related to the instance deletion occurred during the first delete event (you can check the specific error by clicking on the first "Delete" task/logs). The second delete event is a retry, which is not supported in the Technical Preview. I would suggest to have a call to clean up the installation. Best regards, Teodor Simchev

Hi @tandoiluca , The behavior you're experiencing is usually the result of a misconfiguration in Cloud Director's UI/Administration/Public Address settings, where either the load balancer endpoint or certificate is incorrect. You can verify this by running the following command in each cell and observing the specific error.   grep ExecutionFuture /opt/vmware/vcloud-director/logs/vcloud-container-debug.log*   If this is the case, after correcting the public address, you can trigger the reinstallation of the Solution Add-On Management by executing the following two commands from any of the cells. cell-management-tool manage-config -n "vmware.solutions.add.on.bootstrap.completed" -v "no" cell-management-tool manage-config -n "vmware.solutions.add.on.initialize.generation" -v "0" If not, please share the error reported by the ExecutionFuture above. Best Regards, Teodor Simchev  

Hi all, we are having a completly similar problem but using vCD release 10.4.2.2 We have tried to deploy the vAppliance using the UI as per documentation but we have got the following error in creation phase: operation completed with error 1 vcd-ext/cmd/instance/agent.(*waitOperationToCompleteActivity).Run vcd-ext/cmd/instance/agent/activity.go: 490 vcd-ext/cmd/instance.ActivityList.Execute.func1 vcd-ext/cmd/instance/activity.go: 78 vcd-ext/cmd/instance.ActivityList.Execute vcd-ext/cmd/instance/activity.go: 95 vcd-ext/cmd/instance/agent.(*RealizeContext).ExecuteOperation vcd-ext/cmd/instance/agent/common.go: 32 vcd-ext/cmd/instance/agent.(*RealizeContext).createInstance vcd-ext/cmd/instance/agent/create.go: 46 vcd-ext/cmd/instance/agent.(*RealizeContext).Realize vcd-ext/cmd/instance/agent/realize.go: 103 vcd-ext/cmd/instance/create.(*Options).Run vcd-ext/cmd/instance/create/cmd.go: 129 vcd-ext/cmd/instance/create.NewCreateCommand.func2 vcd-ext/cmd/instance/create/cmd.go: 36 github.com/spf13/cobra.(*Command).execute github.com/spf13/cobra@v1.5.0/command.go: 872 github.com/spf13/cobra.(*Command).ExecuteC github.com/spf13/cobra@v1.5.0/command.go: 990 github.com/spf13/cobra.(*Command).Execute github.com/spf13/cobra@v1.5.0/command.go: 918 vcd-ext/cmd/cli.Run vcd-ext/cmd/cli/cli.go:58 main.main /opt/src/vcd-ext/main.go: 13 cause: 'Running Virtual Application vmware.bring-your-own-encryption-0.9.0-appliance(c3a61058-8a8e-4f14-9613-16a61a8b6f72)':'error'   As you can see, strangely, it seems to attempt an access to a GitHub repository which doesn't exist (v1.5.0). Then, we have tried to delete the faulty installation and we encoutered another issue: the delete process failed but it has deleted anything (and it seems the deleting process ha correctly completed because of we do not have any more the vAppliance in the landing zone). The deleting operation failed with apparently the same reason (GitHub problem): operation completed with error 1 vcd-ext/cmd/instance/agent.(*waitOperationToCompleteActivity).Run vcd-ext/cmd/instance/agent/activity.go: 490 vcd-ext/cmd/instance.ActivityList.Execute.func1 vcd-ext/cmd/instance/activity.go: 78 vcd-ext/cmd/instance.ActivityList.Execute vcd-ext/cmd/instance/activity.go: 95 vcd-ext/cmd/instance/agent.(*RealizeContext).ExecuteOperation vcd-ext/cmd/instance/agent/common.go: 32 vcd-ext/cmd/instance/agent.(*RealizeContext).deleteInstance vcd-ext/cmd/instance/agent/delete.go: 37 vcd-ext/cmd/instance/agent.(*RealizeContext).retryInstanceRequest vcd-ext/cmd/instance/agent/retry.go: 48 vcd-ext/cmd/instance/agent.(*RealizeContext).retryInstance vcd-ext/cmd/instance/agent/retry.go: 9 vcd-ext/cmd/instance/agent.(*RealizeContext).Realize vcd-ext/cmd/instance/agent/realize.go: 115 vcd-ext/cmd/instance/create.(*Options).Run vcd-ext/cmd/instance/create/cmd.go: 129 vcd-ext/cmd/instance/create.NewCreateCommand.func2 vcd-ext/cmd/instance/create/cmd.go: 36 github.com/spf13/cobra.(*Command).execute github.com/spf13/cobra@v1.5.0/command.go: 872 github.com/spf13/cobra.(*Command).ExecuteC github.com/spf13/cobra@v1.5.0/command.go: 990 github.com/spf13/cobra.(*Command).Execute github.com/spf13/cobra@v1.5.0/command.go: 918 vcd-ext/cmd/cli.Run vcd-ext/cmd/cli/cli.go:58 main.main /opt/src/vcd-ext/main.go: 13 cause: {"level":"debug","msg":"ISO is not mounted, trying to mounte it."} {"level":"debug","msg":"ISO is mounted."} {"level":"debug","msg":"Verify ISO runner is authored by VMware."} [31mERROR [0m[0005] Unknown command "retry" for "vcd-ext" [31merrorCode [0m=5012000000000000     Now, we are having problem creating a new instance starting from CLI because of the presence of the not deleting instance. How could we forcely remove the previous failed instance? Thanks!

Thanks, Jeff and Nikolay. Please let me recap to check if I understood correctly: - Named disk and template encryption will be supported in the BYOE GA release, including shallow recrypt managed at OrgVDC level. - VM deep recrypt will also be supported in the BYOE GA version as a day 2 operation at VM level. - Named disk and templates deep recrypt will not be supported in the BYOE GA version. Correct? Will Named disk and templates deep recrypt be supported in a posterior BYOE release? Or is it technically unfeasible? Thanks! Miguel

Thanks, Jeff and Radostin. The use case is important to us because some customers need to rotate their keys periodically to meet their security and compliance requirements, and they require deep recrypt. We are aware of the limitations imposed by vCenter for deep recrypt and agree that it makes sense to implement this option at VM level rather that at OrgVDC level, since the VM must be powered off. Your planned implementation seems to meet our requirements. We will check it again in the GA version. Thanks! Miguel

Hi Nikolay, It is great news that you will support the encryption of named disks and VM templates in the GA version. When you say that deep re-encrypt will not be supported in the GA release, do you mean just for named disks and VM templates or for VMs as well? Thanks, Miguel

Hi Miguel and thanks for your question! Yes, you are right with your observation - “Change Key” always performs shallow re-encrypt on the existing virtual machines (VMs) in the Org VDC. All newly created virtual machines in an Org VDC which under BYOE control will be fully encrypted with the key specified by the tenant admin.We are planning to introduce Deep Re-encrypt on a per VM basis. The operation will have a number of prerequisites which come from vCenter: the VM needs to be powered off, it must not have snapshots, etc. We plan to introduce this feature either with the GA or with one of the first BYOE releases afterwards. Please confirm what is the importance of this use case for you?