A few weeks ago, I started blogging about VM service, a new feature of vSphere with Tanzu update 2 which allows developers to created virtual machines with descriptor files, just the same way they do with Pods and Containers.
By that time, I wrote through the eyes of an Operator, which will setup the environment to Developers consume in a secure and control manner.
Today, let’s see how a Developer benefits from a self-service Virtual Machines consumption, enhancing their agility, delivering solutions faster to the marketing.
To start with login to supervisor cluster and make sure your context is configured to the Namespace where VM service has been configured
Documentation page provides a basic template to start with, but if you wanna test my use case, I also published it on my git.
I highlighted some points on the yaml file, those are the critical information you need to provide as follow:
imageName: it’s the template’s name which was made available to your Namespace as part of the Content Library selection:
to list all templates available run: kubectl get vmimage
Along with the templates available for VM Service it also lists templates for Tanzu Kubernetes Cluster (if it has been configured to your Namespace);
className: is that kind of t-shirt size profile which dictates the resources your VM will get.
To list the classes available run: kubectl get virtualmachineclassbindings
The name might not be the most intuitive thing in the world, describe the class to get detailed information about the resources allocated, running kubectl describe virtualmachineclassbindings “class_name”
storageClass: That’s the name of the storage policy where the disks of your VM will be created at:
To list the storage policies available to you run: kubectl get resourcequotas
The first part is your storage policy name
networkName:
that’s the network
name attached to your VM, but it’s ONLY REQUIRED if you are using vSphere
Distributed Switch, otherwise you can remove this specification.
To get the networks available to you run: kubectl get network
In case you get a message like: Error from server (Forbidden):
networks.netoperator.vmware.com is forbidden: User "sso:user@domain"
cannot list resource "networks" in API group
"netoperator.vmware.com" in the namespace "name" it means your Namespace is configured with NSX-T (see topic bellow)
networkType: it’s the solution providing network services to your Supervisor Cluster; it can be vsphere-distributed or nsx-t
For a
developer it’s not something they would know or care about to be honest, to make sure the result you got querying the network is valid you can just describe the network, running kubectl describe network "net_name"
That’s all you need to create your VM.
Well, there’s nothing fancy about creating VMs if we cannot customize it right ?
Customization
of VMs like installing packages, creating files, adjusting settings is
done through the use of ConfigMaps, but this
topic deserves its own blog post. (check it out)
For now, as part of my deployment I also create a ConfigMap which just configures hostname and set up the default password (which will be required to change upon first login).
Just create the VM as you would normally do with any Kubernetes object
In a few
minutes the VM will be available, run kubectl get vm
Also, the VM will be on vCenter inventory under the Developer's Namespace, just as any other VM.
That's what I call Developers freedom !!
