Create new VM but skip Deployment

[KThorlund]

Hi, 

I wonder if it is possible.. I use vRA and vRO to deploy machines and manage them from vRA. Is it possible to deploy a VM via vRA but skip the Deployment part in vRA, so the VM is only available via normal vCenter? E.g when I have made a deployment, can I then destroy the Deployment but keep the VM? in vCenter I see that the VM has a tag vrmManagedMachine = true. 

Can this or similar be done?

Regards, K

[jburen]

Why do you want to do that? When you destroy the deployment day-2 operations are no longer possible. Personally, I don't see any advantage by doing what you want to do.

[KThorlund]

I want to initiate the creation of VM(s) via vRA portal, but I dont want the VM(s) be manageable, nor visible, in the vRA afterwards.

VM(s) should only be available via vCenter when deployed. 

[daphnissov]

It's not possible to my knowledge. Why even use vRA if that's your goal? You're trying to contort a tool which was designed to manage resources as a cloud into a hackneyed way to simply put a web front-end on vCenter. It's not going to work out for you that way.

[KThorlund]

Yeah, why?

Maybe the lack of knowledge. 

Further explained is, that I use vRA/vRO to run a DEV/TEST environment, where users can just request their machines when needed. They can select OS version, memory, CPU, drives, verify names against AD, great requried AD groups etc, which is working great.  

At the same time I have a PRO environment where machines are created manually by a few guy when requested by the users. 

Sometimes I see misconfiguration, e.g. names, CPU memory etc in the created servers, which is a waste of resources for all parts. 

My idea was, that these guys - not the normal user - could also create the machines from vRA/vRO based on all our rules and automation and have these dispatched directly into the PRO environment. 

No mistakes, no manual work, simply just 2 minutes work and we are sure that the machines are always the same. 

The normal user should not have the posibility to create PRO machines. 

Only few IT guys should have the task. 

But neither of them should be able to manage them from vRA. 

Different people do that directly from vCenter. 

So my idea is to simplify peoples tasks, and reduce the change of having mis-configured machines, but keep the way we manage our machines in PRO. 

[daphnissov]

I think this is an instance of not using technology to solve a process problem. You're using vRA/vRO to build out to some of your environments. Why would you then not want to use that same tool to build out Production and get the benefits of not creating snowflakes, not having human intervention and human error, and the same governance and control that you get elsewhere? If there's any place where you do want the benefits of vRA, it's in production. So from that aspect, I'd say that you need to change your process. Regarding the ability for the users who are allowed to provision machines but somehow not be able to manage them, having a difficult time seeing why you'd want to do that. Surely if they have the ability to create machines in prod, install software, manage the config, etc. then they'd have access to do day2. So I'm not following why you'd suddenly want to yank access away. Again, I think this is a process problem and not a technology problem.

[jburen]

I agree with daphnissov that this is an issue with your process and not with the technology. Imho you should use vRA/vRO for the deployment (and management) of VMs. You could create a blueprint for the DEV/TEST and add that to a subscription only for the 'normal' user. Then create another for the PRO environment and make that available to the IT guys. You could limit the day-2 operations in vRA but please, do not try to remove them from vRA. Then in vCenter the VMware guys *could* manage the VM's but why not let them use vRA as well? It's not that you change the config of a VM on a daily basis... So use vCenter for the management of the platform and not for the management of the VM's.

[qc4vmware]

This feels like a rather heated philosophical discussion on how/why to do things but the short answer to your question is yes you can do this.  In fact we do this quite a bit for template management.  We have a process we've fully automated with orchestrator to build out template vm's and also have a XaaS blueprint that our operations people can use to manually kick off a refresh of the environment.  We also build templates on a schedule automatically.  You can make available whatever you can orchestrate with vRO very easily within the catalog of vRA.  If you are not intending to take advantage of vRA though you can just use vRO stand alone.  It has a REST api, integration with vCenter, CLI lots of ways to have people kick off your automations that are user friendly or you can make so with a little work.

[kaushikpal]

Yes that can be done. Create a vRO workflow which does all the tasks like cloning a VM then deploying on a resource pool on basis of user input,joining domain,post builds,etc.And in vRA provide it as a XaaS Service.Your problem will be resolved.

[itrudeau]

Hello KThorlund

Business process are sometimes obscure but indisputable.

Did you take a look at cloud client?

there is a KB talking about removing unwanted vm from vRA using force unregister

Remove the unwanted machine from vRealize Automation by running this command:

vra machines forceunregister --name name_of_the_VM

VMware Knowledge Base

And  if you need to kick this task from vro you can follow this post:

https://clearascloud.com/2015/04/02/calling-cloudclient-from-vmware-orchestrator/

Maybe this can help you out.

[GeiAll]

Hi KThorlund.

You should be able to delete the VM in vRA only if you use the ManagmentModelEntities(Look at vCACEntityManager) . But I would not recommend it. You might end up with alot of work you have to redo on every upgrade of vRA (Database might change). 

But I would suggest another solution for you: 

If you use IaaS Blueprints, you can write an XaaS Blueprint wrapper to start the IaaSBlueprint. (If you allready use XaaS ,you can skip this). 

Then add your vRO server to the vCenter (Register a vCenter Orchestator as a vCenter Server Extension workflow). You can then "publish" the XaaS blueprint directly in vCenter. 

This will make it possible for people with access to the vCenter to deploy a machine directly from the vCenter Web portal, but they do not need access to vRA.(VM will still be visible and handled by vRA).

If they still have access, you can change businessgroup of the IaaS blueprint before you deploy it, making it invisible for "normal" users in vRA.

I use this approch, but that's mosly because the people in charge of vCenters doesn't want to work with several Web-Portals.

[KThorlund]

Great!

Many thanks for all the responses. I can read there are a lot of different opinions, and find what will suit us best.

I agree, that i would be best to keep it all in vRA and manage machines from there. Thou it can be a hard - and radical  - change in an organization.

So my aim was to simplify the deployment to ensure the quality of the creation of the machines, but leave the machine management to the people who has this as their primary task.

regards, K