A colleague of mine was working with a customer recently on some changes to their automated VM provisioning process (they’re not vRA customers… yet). He got stuck trying to get around a particular challenge with the automatic naming of network interfaces in certain Linux distributions.
The customer in question is using vRealize Orchestrator (vRO) to create (not clone) their Virtual Machines from a JSON structure that is supplied by an external system. In that structure there are definitions for the hardware, OS network identity (name, IP etc) and OS installation sources (ISO file for installation and floppy image for a ks.cfg (KickStart) file).
Once the JSON object is provided to the vRO workflow, the VM is created, booted and automatically starts to install and configure itself.
Customer’s Simple VM
Simple VMs have a number of disks defined (for root, opt, var, swap etc partitions) that are attached to a single ParaVirtual SCSI adapter. The VM is also equipped with a single VMXNET3 network adapter.
In this configuration, there is no problem. The installation of the OS runs through to completion and the VM is handed off to Puppet and eventually goes in to service.
Customer’s Complex VM
For the provision of Linux-based Oracle servers however, the customer wanted to be able to specify not only extra disks and partitions, but extra SCSI controllers too. Continue Reading