Emulate "Change reservation" option in vRA with vCO/vRO workflow?

[jhturver]

Hi,

I'm trying to work out how to programatically change the reservation policy and storage policy on vCAC:Virtualmachine as part of a "Change Service Class" day-2 vRA Action via vCO. This needs to include Storage vMotion to a different sDRS cluster/datastore and/or re-assigning VM to a different vSphere storage policy (similar to Cloud Management Marketplace | Solution Exchange).

I've had a look at various approaches including Cloud Management Marketplace | Solution Exchang but the result does not change the VMs reservation policy, and in most scenarios after the VC:VirtualMachine is migrated to alternate storage, there are discrepencies when viewing or editing the properties of the VM in vCAC (e.g. edit VM - cannot see the disk to edit). This is including after forcing a vCAC sync/inventory update.

I can see there are a number of vCAC VM properties that might need to change, and - assuming it's possible - would like to understand the best method of achieving the above while keeping vCAC model consistent with the new storage/VM compute location in vSphere:

e.g.

__reservationPolicyID = 15DE50B9-3740-4EA3-8440-387F4F58FA93

VirtualMachine.Storage.Cluster.ExternalReferenceId = group-p15722

VirtualMachine.Storage.Cluster.Name = ATCA_ITaaS_QATD_Gold001

VirtualMachine.Storage.Name = ATCA_ITaaS_QATD_Gold001

(same for each disk)

This looks like it might provide a way

http://d-fens.ch/2014/02/16/vcac52-change-virtualmachine-reservation-and-storagepath-revisited/

... but context is at time of provisioning and I want to make sure I'm going down a supported path ...

So the question is is there a supported method of updating all of the required properties on a vCACVM individually, or is there a single call to change e.g. vCACVM reservation policy/storage policy that emulates the GUI functionality?

vRA team?

Many thanks for any assistance

Justin

[GrantOrchardVMw]

I vaguely remember that stvkpln did something like this. Perhaps he can chime in.

Grant

[stvkpln]

I toyed with it, but mostly in the context of business group transitioning -- users are in BG's based on their org, not a logical representation.... Without having actually tried / tested any of this, my gut feeling as to the steps that would need to be conducted would be:

1) Perform the storage vMotion

2) Once complete, run a data collection on the compute reservation (I'm going to assume that the compute is NOT changing in this scenario, just the backing datastore / SDRS cluster)

3) One that's done, or in parallel, update the reservation on the VM.

I'm fairly confident (call it 60-70%) that the data collection should update the the custom properties on the VM directly. I ran into a scenario where some VM's on an SDRS Cluster were disabled (for whatever reason), and they were showing up as being attached to one of the datastores, not the cluster itself -- which led to funky errors in the IaaS logs.. After fixing the SDRS  configuration and running the data collection, those errors went away.

NOTE: the big deal with the reservations is making sure BG's don't go out of bounds on the amount of allocated memory and storage capacity for a particular vSphere Cluster (in this instance). Beyond that, and ensuring consistency of the infrastructure, I don't think it necessarily makes *that* big of a deal that the values get updated in real time.

However, this does remind me of something I need to talk to somebody about, so thanks for the reminder, GrantOrchardVMware.

[SeanKohler]

>>>I don't think it necessarily makes *that* big of a deal that the values get updated in real time.

Completely agree.  We also just move the machine and do a data collection.

Just the same... Does anybody know if there is a REST call when the Change Machine Reservation is run?  I got nothing of value out of Firebug.

[stvkpln]

The issue is that the IaaS API isn't really RESTful... It's the legacy ODATA calls. That's (probably, if I had to hazard a guess) why you aren't seeing anything that way. But, I could be wrong....

[SeanKohler]

Sounds right...

[GrantOrchardVMw]

Yes, what Steve said. You can do this with the cloud client, which is how we do the Reservation change for a SRM failover.

Grant

[jhturver]

Ok yeah I have no problem with updates to vCACVM properties not being real-time, but I do see an issue if there is no way to retrospectively update the vCACVM reservation in some automated (vCO) manner as part of the workflow.

- So are you saying there is actually no way to do this programmatically as a day2 operation?

In our scenario this might be more of an issue because the current design uses unique (different) reservations/reservation policies per "tier"

i.e. the vCACVms home reservation (set by targeting a reservation policy ID at request time) will not actually include the new target datastore/SDRS cluster after a storage vMotion from "Bronze" datastore/SDRS to "Gold" datastore/SDRS

Could this be considered a design issue/limitation on our part in terms of what is deemed best practise by experienced designers?

[GrantOrchardVMw · Accepted solution]

If you're asking how would I do it....

I like simple. Simple is easy to administer, troubleshoot, upgrade and change in the future. With that in mind:

1. Put all possible storage tiers into the Reservation.

2. Set a custom property for the "default" tier.

3. Set a day two action to allow a change of "service level" and tie it to an approval policy so that it's not used willy nilly.

Grant

[jhturver]

OK - thanks very much for the feedback on this so far - greatly appreciated

Final comment: Where do I find more info on the "Cloud client" in terms of how to make a retrospective reservation change in vCAC?

(I'd like to investigate this option before changing our current design - although as you say simpler is always better)

[kmarkov]

Hi, I see that it is an year old thread, but I wanted to share what "seems" to be working for me. I have not done extensive testing, yet, since I am still researching. So, it is quite likely that this might not work in all possible scenarios.

However, I found out that using the "Import vCAC Virtual Machine" workflow, part of the vRO library, on the machine I want to change the reservation of, seems to do the trick. I select the machine and set all remaining inputs, but the "hostReservation", to their current values. For the "hostReservation" I select the new reservation.

The execution of this workflow seems to have the desired effect. So far, I have not seen any unwanted side effects.

Krasimir

[jhturver]

Thanks for the input Krasimir - looks promising

I see this is named "Import and IaaS Virtual Machine" in vRO 7, and is embedded into the "Import vCenter Virtual Machine" workflow (which makes sense)

I'll give this a go

[jhturver]

I've tested this quite a bit now, and it works fine for moving managed machines between reservations for the same Business Group.

However, although the workflow will complete when you select a Reservation that maps to a Business Group that the VM is not currently associated with, you will end up with the Deployment object (and potentially other references) still registered in the vRA postgres DB under the original Business Group. This then causes issues if you later try and run a "Bulk Import" to migrate the VM/deployment to a different reservation and/or Business Group (it will fail for that server).

This workflow that used to work well for vCAC 6.x also results in the same issue described above in vRA 7:

http://www.wolowicz.info/2015/07/moving-vms-between-vra-business-groups-and-reservations-in-vco/

The only way I've found to reliably move managed machines between reservations associated with different Business Groups (i.e. move a machine to a different Business Group) is using the Bulk Import functionality which is painful.

Grant / VMware - where is this functionality in vRA 7!?

We need VMware Engineering or the vRO team to provide a workflow (and demonstrate the correct API calls) to do this ....(please please)