I haven't come across this personally.

But it sounds like when guest customization attempts to run on a VM.  I can't remember at what point that the customization packages are created each time a VM is powered on, but this could be the target VM (if it's Linux) or on the vCD Cell where the script is triggering.  If the customization package is absent, I think it generates on deploy but the process to create the kit is on the Cell.

So if you have more than one cell in your deployment, are each configured identically?

Can you try and track logging to see if one Cell works and another fails?

vCD is usually installed as root ... but it's trying to write a log to /tmp with a permission denied.  You should see something in syslog or similar about this in CentOS/RHEL.

Is there any KB people are aware of to clean up the vCD DB or check to see what VM this is erroring out on?

The Org vCD is deleted, but left in stranded items.  Which means it passed a check to allow the deletion, since that's blocked if there is any VM in it (catalog or vapp).

Yet, on purge, it fails with the error DELETE_VRP_CONTAINING_VMS about having VMs in it during validation (priori to actually being deleted).

vCenter shows the resource pool is empty and there are no templates assigned to the pool.

I see it in the vCD Database under vrp_rp and vrp, but don't want to start deleting and miss something.

Full stack trace for the exception is below:

com.vmware.ssdc.library.exceptions.MultipleLMException: Failed to delete object "<name of resource pool / Org vDC>" and its dependencies. - Multiple Exceptions follow: [com.vmware.vcloud.api.presentation.service.InternalServerErrorException: Failed to purge object "<name of resource pool / Org vDC>".]

        at com.vmware.vcloud.common.deletedobject.impl.DeletedObjectManagerImpl.purge(DeletedObjectManagerImpl.java:274)

        at com.vmware.vcloud.deletedobject.impl.ObjectDeletionServiceImpl.executePurge(ObjectDeletionServiceImpl.java:226)

        at com.vmware.vcloud.management.system.SystemServiceImpl.purgeDeletedObjectTask(SystemServiceImpl.java:1609)

        at com.vmware.vcloud.management.system.SystemServiceImpl.executeTask(SystemServiceImpl.java:1563)

        at com.vmware.vcloud.backendbase.management.system.TaskActivity$ExecutePhase$1.doInSecurityContext(TaskActivity.java:653)

        at com.vmware.vcloud.backendbase.management.system.TaskActivity$ExecutePhase$1.doInSecurityContext(TaskActivity.java:648)

        at com.vmware.vcloud.backendbase.management.system.SecurityContextTemplate.executeForOrgAndUser(SecurityContextTemplate.java:43)

        at com.vmware.vcloud.backendbase.management.system.TaskActivity$ExecutePhase.execute(TaskActivity.java:655)

        at com.vmware.vcloud.backendbase.management.system.TaskActivity$ExecutePhase.invokeInner(TaskActivity.java:551)

        at com.vmware.vcloud.backendbase.management.system.TaskActivity$TaskActivityBasePhase.invoke(TaskActivity.java:306)

        at com.vmware.vcloud.activity.executors.ActivityRunner.runPhase(ActivityRunner.java:175)

        at com.vmware.vcloud.activity.executors.ActivityRunner.run(ActivityRunner.java:112)

        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)

        at java.util.concurrent.FutureTask.run(FutureTask.java:266)

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

        at java.lang.Thread.run(Thread.java:748)

Subexception: com.vmware.vcloud.api.presentation.service.InternalServerErrorException: Failed to purge object "<name of resource pool / Org vDC>".

        at com.vmware.vcloud.common.deletedobject.impl.DeletedObjectManagerImpl.purgeObject(DeletedObjectManagerImpl.java:306)

        at com.vmware.vcloud.common.deletedobject.impl.DeletedObjectManagerImpl.purge(DeletedObjectManagerImpl.java:256)

        at com.vmware.vcloud.deletedobject.impl.ObjectDeletionServiceImpl.executePurge(ObjectDeletionServiceImpl.java:226)

        at com.vmware.vcloud.management.system.SystemServiceImpl.purgeDeletedObjectTask(SystemServiceImpl.java:1609)

        at com.vmware.vcloud.management.system.SystemServiceImpl.executeTask(SystemServiceImpl.java:1563)

        at com.vmware.vcloud.backendbase.management.system.TaskActivity$ExecutePhase$1.doInSecurityContext(TaskActivity.java:653)

        at com.vmware.vcloud.backendbase.management.system.TaskActivity$ExecutePhase$1.doInSecurityContext(TaskActivity.java:648)

        at com.vmware.vcloud.backendbase.management.system.SecurityContextTemplate.executeForOrgAndUser(SecurityContextTemplate.java:43)

        at com.vmware.vcloud.backendbase.management.system.TaskActivity$ExecutePhase.execute(TaskActivity.java:655)

        at com.vmware.vcloud.backendbase.management.system.TaskActivity$ExecutePhase.invokeInner(TaskActivity.java:551)

        at com.vmware.vcloud.backendbase.management.system.TaskActivity$TaskActivityBasePhase.invoke(TaskActivity.java:306)

        at com.vmware.vcloud.activity.executors.ActivityRunner.runPhase(ActivityRunner.java:175)

        at com.vmware.vcloud.activity.executors.ActivityRunner.run(ActivityRunner.java:112)

        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)

        at java.util.concurrent.FutureTask.run(FutureTask.java:266)

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

        at java.lang.Thread.run(Thread.java:748)

Caused by: com.vmware.ssdc.util.LMException: Internal Server Error

        at com.vmware.ssdc.util.LMException.wrap(LMException.java:128)

        at com.vmware.ssdc.library.ExceptionFactory.createFromMultiple(ExceptionFactory.java:32)

        at com.vmware.vcloud.common.future.FutureUtil.waitForFutures(FutureUtil.java:85)

        at com.vmware.vcloud.common.future.FutureUtil.waitForFutures(FutureUtil.java:94)

        at com.vmware.ssdc.backend.services.impl.VdcManagerImpl.purge(VdcManagerImpl.java:336)

        at sun.reflect.GeneratedMethodAccessor3646.invoke(Unknown Source)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

        at java.lang.reflect.Method.invoke(Method.java:498)

        at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:333)

        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:207)

        at com.sun.proxy.$Proxy269.purge(Unknown Source)

        at com.vmware.vcloud.common.deletedobject.impl.DeletedObjectManagerImpl.purgeObject(DeletedObjectManagerImpl.java:291)

        ... 17 more

Caused by: com.vmware.vcloud.api.presentation.service.InternalServerErrorException: Internal Server Error

        at com.vmware.vcloud.common.future.FutureUtil.convertExecutionException(FutureUtil.java:210)

        at com.vmware.vcloud.common.future.FutureUtil.waitForFuture(FutureUtil.java:118)

        at com.vmware.vcloud.common.future.FutureUtil.waitForFutures(FutureUtil.java:76)

        ... 26 more

Caused by: com.vmware.vcloud.fabric.compute.ValidationException: ValidationException DELETE_VRP_CONTAINING_VMS

        at com.vmware.vcloud.fabric.compute.vrp.AbstractVirtualResourcePool.delete(AbstractVirtualResourcePool.java:955)

        at com.vmware.vcloud.fabric.compute.vrp.VAppAllocationVirtualResourcePool.delete(VAppAllocationVirtualResourcePool.java:33)

        at com.vmware.vcloud.fabric.compute.vrp.VirtualResourcePoolFactoryImpl.delete(VirtualResourcePoolFactoryImpl.java:319)

        at sun.reflect.GeneratedMethodAccessor9916.invoke(Unknown Source)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

        at java.lang.reflect.Method.invoke(Method.java:498)

        at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:333)

        at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:190)

        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)

        at com.vmware.vcloud.common.diagnostics.GenericMethodDiagnosticsInterceptor.invoke(GenericMethodDiagnosticsInterceptor.java:39)

        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)

        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:213)

        at com.sun.proxy.$Proxy246.delete(Unknown Source)

        at com.vmware.vcloud.fabric.compute.impl.ComputeFabricImpl$DeleteEntityTask.execute(ComputeFabricImpl.java:82)

        at com.vmware.vcloud.fabric.compute.impl.ComputeFabricImpl$DeleteEntityTask.execute(ComputeFabricImpl.java:66)

        at com.vmware.vcloud.fabric.compute.impl.RunnableContextTaskBase$1.run(RunnableContextTaskBase.java:17)

        at com.vmware.vcloud.common.threadpool.ThreadContextExecutor.executeImpl(ThreadContextExecutor.java:59)

        at com.vmware.vcloud.common.threadpool.ThreadContextExecutor.execute(ThreadContextExecutor.java:52)

        at com.vmware.vcloud.fabric.compute.impl.RunnableContextTaskBase.call(RunnableContextTaskBase.java:21)

        at java.util.concurrent.FutureTask.run(FutureTask.java:266)

        at com.vmware.vcloud.common.threading.NDCContextAwareThreadPoolExecutor$NDCRunnableFutureAdapter.run(NDCContextAwareThreadPoolExecutor.java:77)

        ... 3 more

When trying to make merge I get an error:

[ 1f481b03-9047-4eaa-a9e0-3102632ff92b ] Validation errors during merge of Provider VDC.

The VCD entity [vcId=eaa4d8b2-eb18-416e-acd5-7a64b7059f68, more=resgroup-6150] does not exist.

How do you know that he doesn't like? What conditions must be met for the merge?

2018-04-25 18:03:35,957 | DEBUG    | pool-jetty-80             | VC20VirtualEngine              | ResourcePool [vcId=eaa4d8b2-eb18-416e-acd5-7a64b7059f68, moref=resgroup-6150] does not exist in the inventory

2018-04-25 18:03:35,957 | ERROR    | pool-jetty-80             | ComputeHubSetImpl              | Resource pool for [vcId=eaa4d8b2-eb18-416e-acd5-7a64b7059f68, moref=resgroup-6150] doesnt exist

Hi All.

After subscribed to a public catalog when it's trying to upload the files of media or vAPPs it fails with timed out.

Debug log:

com.vmware.vcloud.api.presentation.service.TimedoutException: Timed out.

    at com.vmware.vcloud.fabric.transfer.impl.ReceivingSocketImpl$FileImportResourceFuture.isDone(ReceivingSocketImpl.java:134)

    at com.vmware.vcloud.activity.executors.SupervisedCompletion.run(SupervisedCompletion.java:331)

    at com.vmware.vcloud.activity.supervisors.CompletionMonitor.run(CompletionMonitor.java:51)

    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)

    at java.util.concurrent.FutureTask.run(FutureTask.java:266)

    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)

    at java.util.concurrent.FutureTask.run(FutureTask.java:266)

    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)

    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

    at java.lang.Thread.run(Thread.java:748)

Anyone having similar problem?

Good news!!!

VMware Product Interoperability updated. vSphere 6.7 is compatible with vCD  9.1

Cheers,

Alicia T

Good news!!!

VMware Product Interoperability updated. vSphere 6.7 is compatible with vCD  9.1

Cheers,

Alicia T

Cool, thanks!

A note that although vCloud Director 9.1 is now on the Matrix NSX-V still is not

Problem Resolved. Root cause: Network configuration

For more details: VMware vCloud Director – Subscribe to an External Catalog Feed: Sync issue – BakingClouds

Cheers,

Hi guys,

Is there anybody working with the VCD-CLI in 9.1?

I'm hoping to be able to tell our customers to use this instead of the API to manage their ACLs for ORG VDCs. But so far I'm facing two issues:

1) Based on the command line guide, I don't see a way of applying ACLs based on ldap groups like we usually do through the API. The only possible way seems to be using individual users, which is a bit of a pain.

  vcd vdc acl add my-vdc 'user:TestUser1:ReadOnly' \
  'user:TestUser2' 'user:TestUser3'
  Add one or more access setting to the specified vdc.
  access-list is specified in the format
  'user:<username>:<access-level>'
  access-level is only'ReadOnly' for vdc access setting.
  'ReadOnly' by default. eg. 'user:TestUser3'


Isn't it possible to use groups with the vcd-cli?

2) Even though I unshared the TestVDC and gave access only to my testuser, every other user in that ORG can still manage the "unshared" VDC.


Can anyone confirm that this procedure is working for you?

I can do a list of the ACL's and get as return what I consider to be an appropriate configuration.

-------------------  --------------  ----------

Hi,

I've been searching and searching to find how to configure blocking tasks to provide email notifications using vCD9.1 and vRO 7.3.1. I've managed to connect vRO to vCD using the vRO plugin and both are talking as they should be. I'm not sure on the next steps. Most documents I find are related to vCD 5.5 and don't seem complete. Has anyone managed to successfully do this on vCD9.1?

Thanks.

Hi everybody,

If any one read me or read this i'm happy to give more details and a better way to my old issue.

The way i've propose to add a VM to an organization was not really good and this way was not able to show the permanent VM to the vCloud portal.

I've been forced to rework on this issue and i've taked the problem by another side, and the right way is to use the Import a Virtual Machine as a vApp .

I wish that's will be usefull for anyone.

Regards

@thgreyprnc

I am also facing the exactly the same issue. we have a VCDNI pool which is not vxlan backed, but we already migrated to 6.5. Now we want to add new esxi 6.5 to a new cluster, but the "prepare host" fails in the VCD.

I read your post with the solution, and it was helpful, but i was not able to understand exactly how to manually migrate deom the current pool to a VXlan backed pool.

It will be very helpful, if you can explain it a little.

Thanks,

Sumit

@ArchangelDF

Just saw your reply now. It depends on what you want to do.

In a general perspective, the last version of vCenter supported by vCloud director in order to use the "migrate" function vCDNI > VXLAN is version 6.0U3.

But of course in order to have this migrate function available in the first place you might have to upgrade vCD to an intermediate version. Version which is still supporting the version of vsphere you are currently running

If possible, I would : upgrade to vCD 8.20 > use the migration function on a test org vdc to migrate from vCDNI to VXLAN > apply on the prod > finally update vCD to 9.1

So first thing to do is to check the different interops in order to know from where to where you can go and compatible with what : VMware Product Interoperability Matrices

@sur_sumit

No prob, it happened so often that I was helped on the internet without having the good opportunity to give something back, I tought this was the right one

What i suggest you to do is :

1) in a first step create a new, test org VDC, in which you create a vapp with 2 vm's to which you associate a test network backed by your existing vCDNI pool.

2) be sure to manually place each of those vm's on a separate physical host (the goal will be to validate that vxlan packets are flowing between physical hosts)

3) run a ping -t each vm from each other and validate that everything is working

4) power off that vapp

5) from the org vdc > my cloud > vapp > virtual machine > properties > hardware > network > none

6) from the org vdc > my cloud > vapp > networking > delete the org vdc network

7) from the org vdc > administration > org vdc networks > delete the network

8) from system > manage > organisation VDCs > right click/properties > network pool&services > switch the network pool to your VXLAN pool

9) from the org vdc > administration > org vdc networks > recreate the network

10) from the org vdc > my cloud > vapp > virtual machine > properties > hardware > network > assign the new org vdc network object

11) poweron the vapp and confirm network connectivity is OK

Then I suggest you properly document, for each org VDC, all network settings and do previous setps at the end, when all your org vdc's will be migrated to VXLAN you will be able to delete the vCDNI pool which, in turn, will allow you to join your 6.5 hosts cleanly. Like I said, pay especially attention if you are using IPSEc tunnels since they will be deleted at the moment you will finish delete your vcdni org networks (at least it was my case).

With both the hosts on 5.5 , right?

Is it possible to have each org utilize the same IP space as each other. That is can all 5 Orgs in VCD utilize the same /24. All orgs have to be able to go out to their own MPLS connection, as well as a shared network segment with shared services. If each Org had their own IP space this would be pretty straight forward, but we are worried about conflicting IP space with the clients that are coming in through the MPLS.

Or are we thinking about this all the wrong way?

Will it require some downtime?

Each VXLAN in VCD is segregated by design from the others, allowing overlapping IP ranges, You can obtain the same the same separation also when using external networks backed by VLANs.  As long as the traffic goes straightforward from the VMs on the VCD VXLAN/VLAN to a dedicated MPLS device and then to the clients on the remote side (and viceversa) I don't see any problem.

Best regards,