Hi,
Since you are a multi-tenant Cloud provider, Can a Customer bring any Microsoft license to your environment? Do you provide Microsoft Licences to your customers? You should certainly read
Just by looking /fetching the compute resource one cannot determine what DB/Application is running inside the VM
I am using NSX with vcloud 5.6 and VXLAN network pool creation fails with "[ 9d227524-e462-4ecf-94b3-8ed4cdf8ef38 ] VSM response error (100): null"
Error trace:
| 2015-08-19 16:28:11,032 | ERROR | | backend-activity-pool-14 | TaskActivity | | [Activity Execution] Unable to execute task 'TaskModel [id=32d9be60-175f-403b-a69c-d7725d1ddf11, orgName=System, cellInstanceId=41, targetId=f5debfec-e67a-4f2a-a026-20910bd7e514, jobId=6a7e36e6-35ff-4ef6-8348-c11697ff016c, operation=NETWORK_REPAIR_NETWORK_POOL, taskName=NETWORK_REPAIR_NETWORK_POOL, retriable=false, status=running, version=2' - Handle: urn:uuid:6a7e36e6-35ff-4ef6-8348-c11697ff016c, Current Phase: TaskActivity$ExecutePhase, ActivityExecutionState Parameter Names: [NDC, TASK_JOB_ID, activityPhaseStackList] | requestId=e69c2f57-a012-42a3-a490-9a91b276556c vcd=46ef3bf5-7c9e-473a-973b-707f69b2d943,task=6a7e36e6-35ff-4ef6-8348-c11697ff016c activity=urn:uuid:6a7e36e6-35ff-4ef6-8348-c11697ff016c |
com.vmware.vcloud.fabric.nsm.error.VsmException: VSM response error (100): null
at com.vmware.vcloud.fabric.nsm.error.NetworkSecurityErrorHandler.processException(NetworkSecurityErrorHandler.java:95)
at com.vmware.vcloud.fabric.nsm.error.NetworkSecurityErrorHandler.handleError(NetworkSecurityErrorHandler.java:70)
at org.springframework.web.client.RestTemplate.handleResponseError(RestTemplate.java:494)
at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:451)
at com.vmware.vcloud.fabric.net.utils.impl.LoggingRestTemplate.doExecute(LoggingRestTemplate.java:64)
at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:409)
at org.springframework.web.client.RestTemplate.getForObject(RestTemplate.java:207)
you'll probably need a support request to get assistance from the vCloud and NSX team to resolve this.
anytime i have seen the VSM response error (100), there is some brief work on the internal parts that is best fixed with guidance from support.
Hi,
There is a table 'VM_INV' in vCD database, finding out date entries with the equivalent MOREF on that table and cleaning it up.
I need to orchestrate and integrate from VCD, and can't use VRA as my front end. What is the current state of integration between VCD and vRealize Orchestrator?
Can I safely assume that any custom workflows or integration I need to add to my VCD deployment can continue to be done with vRO?
I'm seeing this "ESX Agents" resource pool too, deleting it causes it to be recreated instantly in vcenter. Didn't appear until i enabled HA on my VSAN cluster.
It looks like a stale Org vDC entry in vCloud director. Deleted and recreated OvDC it to fix this issue.
This question is really what i want to know.
Can i clone a linked-clone(fast provision) vApp to a full copy vCenter VM ?
If you perform the clone operation from vCenter you will end up with an independent disk. You can also export the vm to an ovf/ova then re-import. There is also the VMware Converter which can perform a v2v.
Hi,
is any possibility to migrate all catalog items (temps and iso files) to another datastore cluster which has same storage profile (silver)? Because I have 2 datastore clusters with same storage profile (silver) and I want to remove one of this cluster.
I found this kb: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2058094 but they only wrote about migration media files between different storage profiles.
Have vCD 5.6.4
Do you happen to use Fast Provisioning? That's probably the only catch I can think of.
Environments which do not have Linked Clones or shadows created from them, you can just Storage vMotion them between Datastores of the same Storage Policy. Just make sure that the Datastore or Datastore clusters are visible in vCloud Director first under that Storage Policy.
When using linked clones, I can't remember the exact process ... I think I have it at my desk somewhere (I'm at home now).
I believe new shadow VMs get instantiated on other datastores in the datastore cluster if it doesn't exist when we we migrate the linked clone VM's across the datastores.
I contacted with VMware Support and I received this answer (as you can see process to move media is impractical, especially when you have a lot of clients and you must check all their files...):
2 Storage Clusters
Gold - Gold Storage Policy
Silver - Silver StoragePolciy
1 Catalog with storage as Gold
Task
1) Change storage policy of catalog to silver
ISO still has not changed datastore or storage policy
2)Updated ISO by adding test in the description box - No change in any of the iso's properties
3)Created new catalog called Silver using the silver storage policy
4)Moved test.iso from test cataog (gold) to copy-move catalog(silver)
The task verified in Vcenter and now test.iso shows as silver storage policy and has moved to a datastore with the silver policy
Test 2
1)Chnage the storage policy of the copy-move catalog to Gold
2)Disabled storage of a datastores that belong to silver storage policy
3)Put into maintenance mode all datastores belonging to silver storage policy in vcenter
No iso's were migrated from this datastore automatically
When updating the ISO this did not change Storage Policy
Test 3
2 datastores in Gold storage cluster
iscii has iso-test - put this datastor into maintenance mode
Update iso in vcloud, this forced a move of the iso to other datastore
Conclusion
To change the storage policy of a media file a new catalog must be created and the media file manually moved.
To change the datastore of media that belong to the same storage policy in a storage cluster, put the datastore into maintenance mode and update the iso in Vcloud. The media file will then relocate to the next available datastore in the cluster.
As you can see in my last post this process is not easy, fast and it's impractical.
This is a behavior change I've noticed since upgrading to VCD 5.6.3.
Previously VCD would install the VIB for this by default, but starting with 5.6.3 it does not. This is apparently a feature called "agentless mode", and VMware has a KB that reflects how to enable it: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2092713
However, it doesn't seem like it's supposed to use this behavior by default. There's nothing in the documentation to reflect this behavior change, so it appears to me that this is a bug.
As a workaround, make a backup of /opt/vmware/vcloud-director/etc/global.properties, then edit the file and add the following:
backend.installHostAgentForVcdni = 1
You will need to do this on each cell, and restart the VCD services afterwards. If your host is already in use, you need to take it out of service, un-prepare it, then re-prepare it.
Instead of hacking away at the database, (which is not supported) check the "Stranded Items" folder.
Missing VMs should be listed here, so you should be able to purge the already-deleted VM from VCD that way.
This will not show the object which is already deleted from vSphere.
If he's using VXLAN exclusively, then the vCNI Capable check mark is meaningless. It's actually worse to have the agent installed since then you have to do some work to get the host unprepared if you ever need to do so (specifically maintenance mode).
As long as we understand why the check mark isn't there and are fine with it, there really is no action to be taken.
With the focus on vCloud Director based service providers moving to NSX/VXLAN, I personally think you're better off agentless + vxlan than using vCNI. To align the other hosts, you'd have to unprepare/prepare them again. it would be good to use the KB and ensure the config is in the database to force agentless mode.
As for the KB, I'm the person who drafted that. it's best to use the database option so you don't have a global config setting local to each cell. if you happen to add a new cell and forget to add the line, then you have an inconsistent configuration in the future.
Stranded Items is for when an object is "to be deleted" in vcloud director, but we fail to perform the delete task in the appropriate system (vCenter/vShield/NSX).
This is quite the opposite, which is the VM is in a vApp in an Inconsistent state (vCD thinks it's powered on, vSphere doesn't have a power state since it's missing from inventory).
I'll ask around if there is an easy way to fix this. the key point will be getting the VM into an Off state in vCloud Director, then it should delete without issue.