laurent2502
Contributor
Contributor

VMware vCloud Director installation process with NSX Manager.

Jump to solution

Hi everyone,

I recently planned to deploy VMware vCloud Director (so NSX Manager will be deployed too, as a part of the process) on an existing environment (existing running VMs, virtual switches,...).

Customers are using their VMs since they are in production.

I was wondering whether the deployment / installation of NSX Manager would cause any downtime or disturb running workflows or even break VM interconnections ?

Thanks in advance,

Laurent B.

0 Kudos
1 Solution

Accepted Solutions
IamTHEvilONE
Immortal
Immortal

I've watched many tutorials and indeed nothing should happen until I deploy a controller or something else. My concerns were about this "else", like virtual switches and so on. I guess NSX will display existing resources such as existing virtual switches (and so on) already configured with vCenter ?

What vCloud Director does is interact with NSX via API.  The calls are exclusive to VXLAN (vdnscope-## resources in the API) and the request to deploy or update an edge.  vCD doesn't "display" resources discovered by NSX.  You configure NSX and then vCD Makes an API call and says "I want an edge connected to port group A and B" or "I want a new vWire from this VXLAN instance". 

Is there any document with "best practices" for vCD deployment ?

Yes: VMware vCloud Architecture Toolkit: Cloud Computing Reference Architecture | United States

The meddle with existing resources, is to have dedicated resources for the Provider vCD (aka cluster in vCenter).  It's preferable to have that then using a resource pool of a cluster where noisy neighbor problems can occur.  the vCAT above will go over a lot of that when you read it.

View solution in original post

0 Kudos
11 Replies
IamTHEvilONE
Immortal
Immortal

It shouldn't change things initially.

When vCD is deployed, it doesn't even connect to a vCenter until you configure one.  Once you configure a vCenter and the associated NSX manager, nothing should be deployed automatically until you do something ... like create a network or request an Edge.

Ideally, your vCD deployments should be in a dedicated cluster to isolate Tenants from the rest of your environment.  In that sense the VXLAN vWires (if used) go to the distributed switch as configured in NSX manager, then edges are deployed and associated to these new wires in the corresponding cluster.

Unless something went terribly wrong, or you meddle with existing resources, I don't really see how there could be downtime incurred.

0 Kudos
laurent2502
Contributor
Contributor

When vCD is deployed, it doesn't even connect to a vCenter until you configure one.  Once you configure a vCenter and the associated NSX manager, nothing should be deployed automatically until you do something ... like create a network or request an Edge.

I've watched many tutorials and indeed nothing should happen until I deploy a controller or something else. My concerns were about this "else", like virtual switches and so on. I guess NSX will display existing resources such as existing virtual switches (and so on) already configured with vCenter ?

Ideally, your vCD deployments should be in a dedicated cluster to isolate Tenants from the rest of your environment.  In that sense the VXLAN vWires (if used) go to the distributed switch as configured in NSX manager, then edges are deployed and associated to these new wires in the corresponding cluster.

Is there any document with "best practices" for vCD deployment ?

or you meddle with existing resources

What do you exactly mean by this ?

Thanks for your quick answer,

Laurent B.

0 Kudos
IamTHEvilONE
Immortal
Immortal

I've watched many tutorials and indeed nothing should happen until I deploy a controller or something else. My concerns were about this "else", like virtual switches and so on. I guess NSX will display existing resources such as existing virtual switches (and so on) already configured with vCenter ?

What vCloud Director does is interact with NSX via API.  The calls are exclusive to VXLAN (vdnscope-## resources in the API) and the request to deploy or update an edge.  vCD doesn't "display" resources discovered by NSX.  You configure NSX and then vCD Makes an API call and says "I want an edge connected to port group A and B" or "I want a new vWire from this VXLAN instance". 

Is there any document with "best practices" for vCD deployment ?

Yes: VMware vCloud Architecture Toolkit: Cloud Computing Reference Architecture | United States

The meddle with existing resources, is to have dedicated resources for the Provider vCD (aka cluster in vCenter).  It's preferable to have that then using a resource pool of a cluster where noisy neighbor problems can occur.  the vCAT above will go over a lot of that when you read it.

0 Kudos
laurent2502
Contributor
Contributor

I see.

vCD doesn't "display" resources discovered by NSX.  You configure NSX and then vCD Makes an API call and says "I want an edge connected to port group A and B" or "I want a new vWire from this VXLAN instance".

When I ask all this, my concern is to be able to manage all my infrastructure (pre-deployment existing resources and post-deployment new configured virtual devices) from a "single point". I mean that I don't want to have to manage "old" virtual devices from point A and new ones deployed with NSX from point B. As an additional layer on top of my current infrastructure which enables me to do whatever I want. Here I would have :

- NSX Manager through vSphere Web Client I guess, which would enables me to manage old and new virtual devices

- vCloud Director, which would enables me to configure tenants, manage VMs, vApps, Resource pools,...

Is the representation I made right here is correct ? Or maybe I didn't understand how it really works ?

Thanks for the document by the way.

0 Kudos
IamTHEvilONE
Immortal
Immortal

It'll pretty much be the A/B scenario, unless you import existing systems to be managed under vCloud Director.  that's another story, but is possible.

I'm probably missing more from your use case, but you'll still need the vSphere Client for host maintenance and other things anyways ... and you would not use it to manage vCloud Director provisioned systems

0 Kudos
laurent2502
Contributor
Contributor

It'll pretty much be the A/B scenario, unless you import existing systems to be managed under vCloud Director.  that's another story, but is possible.

Is it an easy process to do this ?

I'm probably missing more from your use case,

Actually we are "IaaS" service providers. We manage a cloud infrastructure and customers use it for their VMs. The reason why we want to deploy VMware vCloud Director is that we want to provide them access to the resources of their VMs (RAM, CPU and so on). We also want to enable them to deploy new VMs or vApps...

But as an Administrator, I would have been happy to have a single point of configuration. But in the worst case, I'll get by with it as such.

0 Kudos
laurent2502
Contributor
Contributor

Hi again.

I've finally finished installing vCloud Director and linked it to my vCenter and NSX. But when It's done, I'm even not able to create a Provider VDC. Indeed, it asks for a Resource Pool to be linked to this PvDC and none of existing Resource Pool is displayed to be chosen. I don't even see my hosts which are managed by the vCenter I've linked to vCloud Director.

I've looked everywhere in the GUI and I didn't find any way to import existing managed host or Resource Pools. Only Distributed Switches and Port Groups are displayed in vCloud Director.

Can you help me ?

Thanks in advance.

0 Kudos
IamTHEvilONE
Immortal
Immortal

To make a new provider you need to meet the minimum requirements, and only after creating a provider vDC will hosts actually show in the GUI.

When creating the Provider vDC

1. You can only import a Cluster or Resource Pool object, not an individual host

2. You must have DRS enabled on the cluster (DRS is also a requirement for Resource Pools to exist)

3. Once you have selected the Cluster/Resource Pool, the associated hosts should appear later on in the Wizard.

0 Kudos
laurent2502
Contributor
Contributor

I see... I feel silly now since I was making tests on a single ESXi host just to see features and test them with a few resources and machines... I can't go further then until I add at least 1 host to make a cluster and turn on DRS...

Thanks, I'll do this.

0 Kudos
IamTHEvilONE
Immortal
Immortal

yeah, you aren't the first to get caught by this.

When you make an Org vDC, vCloud creates a resource pool to represent it ... which needs DRS, and DRS needs at least 2 hosts in a cluster to be turned on.

0 Kudos
laurent2502
Contributor
Contributor

Hello again,

I finally built a cluster of 3 hosts and tried to do it like our production environment so that tests are more relevant.

I created resources pools and put VMs into them because that is was our production environment looks like. Every customer has its own resource pool with his VMs in it.

Then I created a Provider VDC, which creates a Resource Pool. Then an Organization VDC, which creates again a resource pool but not in the PvDC... I'm a bit confused with this, I thought it would have been a "sub-resource-pool" but no. But whatever...

Then I realized this approach of creating a resource pool was pointless because the OvDC created one. So I moved its VMs to the OvDC. Then I log on the Organization admin account in order to see if I can see the VMs I moved into it, but I don't see them. Does that mean I have to transform them in Templates then create a vApp in the catalog of the organization so that they can deploy it again ?

I'm a bit confused on how to match vCloud Director with my existing environment. On a brand new one I think it would have been a piece of cake since there isn't anything to deal with, you start from scratch.

Here, It's different because I can't do whatever I want since it is supposed not to interfere with runnings VMs. I can't shut them down to re-deploy them so easily.

Do you think my use case is possible and do you have any advice for me ? I'm a bit confused.

Thanks in advance,

Laurent B.

0 Kudos