[vrO] 20x Linked Clone Linux with static IP

[AdminOnTheRun]

Hi

The actual situation

Uur students access Linux training VMs via RDP.

Currently I am rolling these VMs out via a script.

In the future

I would like to realize this via a vrO workflow which I would like to offer as xaas in vrA.

Creating 20 multiple linked clones is not a problem, but I can't manage to assign every machine a static ip from a specific pool.

It`s crucial that the VMs have the same range of Ip address after every roll out.

Do you have an idea how I can solve this problem?

Thanks a lot for the support

Christoph | vrO beginner

[daphnissov]

If you did this in vRA, it is quite simple using network policies. I wouldn't do it as XaaS because it takes that off the table. vRA has the ability to do linked clones natively through IaaS requests, and for customization you have a whole host of things from vRO workflows to Ansible to software components.

[eoinbyrne]

Agree with daphnissov​ - vRA can do what you want OOTB

You would use a Reservation & NetworkProfile for a LinkedClone Blueprint for one VM & then @ request time just set the instance count to 20.

If you need specific hostnaming format, network placement, VM sizing or extra disks, you could overlay those features with XaaS afterwards.

[AdminOnTheRun]

Hey,

thank you for the super fast answer

I see your point with vrA and did some research about network-policies, but there is a problem my brain will not overcome and you couldn't know because I forget to mentioned it in my first post, sorry!

More detailed explanation:

The current workflow is as follows:

Step 1) A lecturer asks for a VM, which we make available via the vCenter. (Clone a  Linux template)

Step  2) Now he sets up his VM for the training. (Over a static IP via RDP)

Step  3) Then I create 20 clones with static IPs using a mix of pearl and bash script.

Step  4) Via RDP the students can now login to the VM.

Step  5) After the training we delet all Linux VMs in the vCenter

As you can see, there is a lot of manual work I like to get rid off.

The new workflow I hope to archive:

Step 1 & 2) The lecturer creates the Master VM himself over vrA and set up it up. (I configured everything for this step already)

Step 3 - scenario 1) The teacher clones his Master VM from step (20 piece) and assigns one of six ip areas to the clones over vrA. (This is the Part I try to find a solution for and thought about vrO)

Step 3 - scenario 2) I clone his Master and choose the IP range.

Step 4) Via RDP the students can now login to the VM.

Step 5) A XaaS action delets VMs from name pattern X or ip-range Y (This shouldn't be a big problem I hope)

Thanks for the help

Christoph

[daphnissov]

Yes, this is all possible but with a slight modification. It would look something like this:

1. Administrator creates a vSphere template in advance with the needed base packages, applications, etc.
2. Administrator creates automation via some method to perform last-mile setup after deployment.
3. Administrator snapshots vSphere template created in step #1.
4. Administrator creates a blueprint in vRA (you keep writing "vrA" and "vrO" but it's "vRA" and "vRO") that selects the template from step #1 and configures it as a linked clone.
5. Administrator creates a network profile in vRA with a range of IPs that vRA is allowed to consume.
6. Teacher logs into vRA portal and requests this catalog item which allows the teacher to specify how many copies of the VM that should be provisioned.
7. vRA provisions X number of linked clones from the template in step #1, pulls then sets an IP from the network profile in step #5, and sets a hostname. All this happens automatically.
8. vRA runs last-mile automation on each resulting VM for the final configuration/deployments steps. This happens automatically.
9. After provisioning is complete, teacher hands over the IP addresses to the individual students for them to access their VMs.
10. Once the class is complete, teacher goes into vRA and destroys the deployment containing the X number of linked clone VMs.
11. vRA completes the deletion and clean-up process automatically, freeing up the consumed IP addresses.