Hi. Good day. Hello. At the very beginning, I would like to apologize to all my readers and observers for not providing you with new content for a long time. A lot has changed for me since the last time. As you surely know from my previous posts, I worked for a VMware integrator and partner for a while, which was very interesting because I could touch real VMware in 30 percent, from the inside.
Back then, it was ticket resolving, and I personally always wanted to do more. What I didn’t receive, that’s why I happily changed my employer and came back to my favorite part of VMware, namely Cloud. Finally, I can touch Cloud Assembly, VRO, NSX and other elements related to the cloud again, for which I thank my current employer which is ATOS.
Recently, I got a seemingly trivial topic to invest, namely changing the network network in a virtual machine after deploying, which has already been used for some time in the VM.
As I said, the topic may seem obvious, but not here.
VMware what are you thinking??
Unfortunately, we don’t get this out-of-box option, I touched on my contacts, searched the documentation, looked into the deepest corners of the Internet and nothing.
Again VMware what are you thinking??
So I started testing the solutions from the simplest to the one about which this article is, but one by one. It might seem that since Cloud assembly sync with vCenter every 10 minutes, changing the connection of the network card to vCenter will reflect on Cloud assembly but not here. So the solution went to the trash.
The second way was to use the built-in Update Deployment option, but here, although we have the ability to change the network, unfortunately, or maybe fortunately, I tested it in the GUI and on the second tab, before pressing confirm, two steps appear to me. The first is to redeploy a new machine and the second is to change the network network.
but wait a minute, how is it redeployed, does it mean that I will lose all the data that was on the machine so far, stop, we don’t go this way. The second walkthrough goes to the trash
Time to delve into the API, unfortunately also here nothing good VMware has prepared for us, therefore this path turned out to be closed.
So we come to the brilliant plan that was born at 8:30 PM one evening and at 11:30 PM was 90% complete with some to-do elements as an improvement, but more on that later. This plan was to write a workflow.
Some APIs come with help, as well as built-in vCenter plugin functions.
But let’s start from the very beginning. The plan is this, we accept two variables on the input, namely Network Name and VM Instance UUID.
Thanks to the use of Instance UUID, we are able to download all required VM data both on the Cloud Assembly and on the vCenter
Before I started fetching information about the VM, I figured it would be a good idea to validate the network. I will do this validation based on the API available in IAAS regarding the fabric-network
iaas / api / fabric-networks
var networks = JSON.parse(response.contentAsString).content
for (n in networks)
{
if(networks[n].name == networkName)
{
System.log("Change is possible")
}
}I will not quote the entire code here because what counts is the idea that in my opinion is stronger than sharing full codes, but for those willing this year I also decided to add GIT to my blog along with all codes.
So, after validating the network, I download all the data that is available in the next API
var url = “iaas/api/machines/?$filter=customProperties.instanceUUID%20eq%20″+instanceUuid
the data I need
var vmProp = JSON.parse(response.contentAsString).content[0];
var jsonResponse = response.contentAsString
projectId = vmProp.projectId
deploymentID = vmProp.deploymentId
resourceName = vmProp.hostname
vcUuid = vmProp.customProperties.vcUuid
resourceId = vmProp.id
endpointId = vmProp.cloudAccountIds[0]
System.log(jsonResponse)
Another element of my wokflow is to download tags from the virtual machine, of course tell me why you didn’t do it in the previous step, but I like to have it all sorted out and it’s easier for me to debug or troublshooting later.
In this step, I also refer to the API
iaas / api / machines
however, it no longer searches the entire database that is available on the entire Cloud assembly, only the previously downloaded resourceId.
Now my first consideration is what to do with the old deployment. You know, you can delete it, but then we lose the VM, so the question is where should it be removed, but again, do you really want to delete it and not be able to return? I decided to make a backup by changing the deployment name
I use the API twice here
/ deployment / api / deployments / “+ deploymentID
The first time I get the deployment name using the previously downloaded deployment ID and then using the PATCH API I change the name giving the name with the annotation -backup
deploymentName = JSON.parse(jsonResponse).name
var params = '{"name":"'+deploymentName+'-backup"}'
It looks like everything we could do at the Cloud Assembly has just ended. So now I’m going to work directly on vCenter.
Setup is simple here. First, with vcUuid I find the correct instance in vCPlugin.allSdkConnections. Then, in the newly created connection, I find the virtual machine object using the previously downloaded instanceUuid.
When I have the machine object, it starts working again. First, the machine must be turned off. Here, it uses actions built into vRo
System.getModule (“com.vmware.library.vc.vm.power”). ShutdownVMAndForce (vmObject);
The next element is very important because this is where the “magic” will happen, which will allow us to change the network. More specifically, we will clone the VM, but in order to be able to do it automatically, we need to download some data from the object of the virtual machine
- Folder -> VC:VmFolder
- Name -> string
- Power Status -> boolean
- Template -> boolean
- Datastore -> VC:Datastore
- Pool -> VC:ResourcePool
- Host -> VC:HostSystem
- ThinProvisioned -> boolean
Fortunately, we are able to download it all from our facility, because we want the new machine to be in the same place.
The next stage is usually cloning the machine, using the built-in cloneVM actions and waiting for the task to be completed on vCenter vim3WaitTaskEnd.
After cloning here, unfortunately I have to unregister the old Virtual Machine. This will cause us to crash the Deployment which we have backed up, but we will still be able to recover this machine.
At this point I must say that we have an element that I would like to implement, but in the environment I have vSAN, so I cannot use it. I mean changing the names of virtual machines. I would like to change the old one to backup and the new one to the old one. Renaming is allowed but I can’t do svMotion to change all files. Although the code is written, VMware did not provide for such a solution. I also saw an entry on VMTN on the network that such a problem was reported to VMware last year, so I’ll wait patiently.
After unregistering the old machine, I can take care of the new one. Here I have one small minus for myself, but maybe also for VMware because I can search this VM in a similar way as before, but using the name in this case because I have nothing else, and cloning does not provide me with such data.
After finding a new machine. We inject it with the VcVirtualMachineConfigSpec () instanceUuid we saved from the old machine. We do this because we want to continue executing Day-2 actions on this machine using its instanceUuid.
Now, using the name of the network that we validated earlier, we create the VC object: DistributedVirtualPortgroup, which, using the same configuration or as I did with the new one, we prepare and inject the changes in our machine. We use the built-in reconfigureVM_Task solution for everything.
When the whole process is successful, we can return to the Cloud Assembly.
We are changing the API, from IaaS and Deployment to Onboarding.
Using the API / relocation / onboarding / plan with the parameters that we collected throughout the process
var params = '{"name": "' + onboardingName + '", "projectId": "' + projectId + '", "endpointIds": ["' + endpointId + '"]}'We create an onboarding plan.
We need to add deployment to the plan and here we also use API / relocation / onboarding / deployment. And the parameters we collected during the process
var params = '{"name":"'+deploymentName+'","planLink":"'+planLink+'"}'Now there is an activity that I am not entirely proud of, but it is just 11 minutes sleep which will give the Cloud Assembly time to do the Data Collection so that we can add our new machine to the onboarding plan.
When time is up, Cloud assembly during the Data Collection gives a resourceID to all elements it reads in order to find them in its database. Therefore, we can use the API relocation / api / wo / query-unmanaged-machine, which, with the given parameters, will find our VMke in the spheres of others not managed by the Cloud Assembly and download its resourceID
var raw = JSON.stringify({
"planLink": ""+planLink+"",
"optionExcludePlanMachines": true,
"optionIncludeOnlyPlanMachines": false,
"filters": [
{
"field": "NAME",
"values": [
""+newName+""
]
}
]
});Having an ID, we can put everything together, assign it as resources to the Plan using the API
relocation / onboarding / resource and parameters
var raw = JSON.stringify({
"resourceLink": ""+resourceLink+"",
"resourceName": ""+newName+"",
"deploymentLink": ""+deploymentLink+"",
"planLink": ""+planLink+""
})The last element of onboarding is the plan execution, which we do through the next API / relocation / api / wo / execute-plan
In this way, we returned the virtual machine to the cloud assembly with the same deployment name as well as the same instanceUuid and, most importantly, the changed network. Unfortunately, just like me, having only one disk resource, which is vSAN, also the name of the virtual machine is changed, which at the moment does not bother me, but I would like to correct it in the future.
In my workflow I restore the tags so that the VM is marked as it should be and I remove the onboardign plan to leave a clean environment.
Here you can see what the whole workflow looks like and as I promised, it will be available on my GIT soon
I personally think that this is not the end yet. Because in my opinion the elements that should be refined is the removal of the old deployment, which of course can already be done when unregistering the VM from vCenter, that’s why I have it on my short to-do list. However, in my opinion, another thing worth spending some time with is cleaning the vCenter from the machine because removing the deployment will not remove the old machine. And just like in my case, I still have to investigate and if there is such a possibility, code IPAM management, because while removing the deployment will release the IPAM address for us, onboarding this address will not reserve us.
So I have something to do and to those who have reached this point, thank you very much for reading the entire article. I hope that I helped you a little bit and if someone from VMware also reads this article, please think about an out-of-box solution that allows you to change the network without cloning the VM