Just Another IT Blog

It's time to share some of my experiences, crazy ideas, tips and tricks !!!

Post Page Advertisement [Top]

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 !!

 

 

 

Bottom Ad [Post Page]