Hello World! ![]()
I'm actually studying vCloud Director as Lab Manager "replacement". As you now Lab Manager is not supported on vSphere 5, so we've decided to move to this new product in order to have "at least" the same functionality of the "no-more-supported" vmware old software....
As we use Lab Manager:
we use It just for create isolated virtual DMZ in order to have multiple copies of some particular vms for software developing purposes (in this way, we avoid the IP & hostname duplicate issue). Of course, the Service VM provided by Lab Manager was not sufficient for NATting... that's why we put a "stupid" monowall in order to do advanced Nat & Pat.
in vCloud, I was able to reproduce the same use case ... BUT... I've the suspect that the integrated vShield Edge does not allow me to NAT from a private LAN ip address ... isn't It? It seems that want a public IP to put into the "NAT - External IPs" tab.
Does exist some kind of workaround?
thanks in advance
Hi,
There are 2 different levels of vShield Edge, you need to understand.
The first one is at the Organization level, which has an ""NAT - External IPs" tab. As you can probably imagine, when connected to an external network as a Service Provider, you need to keep a complete control on the "physical" side, which explains this specific field that "only" a vCloud Admin can change. (you might not "need" this one in your environment)
I think what you are trying to achieve relies in the second one, the vShield Edge at the vApp level.(the IP of the edge will be provisionned automatically in your Org Network pool)
This one will allow you to deploy complete environments that you will be able to duplicate multiples times. (you can do either ip translation, or port forwarding, whatever fits your needs)
So you can do this pretty easily in vCloud Director without adding another monowall appliance ![]()
Hope this helps,
Hi Timo,
Thank you for the answer.
So you mean that I don't need an organization network but I need to create a vAPP network.... Isn't it?
Sorry but the documentation is not really clear (at least for me) and it was really hard to understand the new way of work of this product. In fact, I'm start to thinking that vCloud is not really the successor of Lab Manager but in some way and probably with some tricks, it can become...
Well if it's about "we use It just for create isolated virtual DMZ in order to have multiple copies of some particular vms for software developing purposes"
This is a very good use case for vCloud Director and it does work very well. (we use it internally for that purpose on a very big scale, and if you happen to go to VMworld, all the Hands On Labs are built with this)
You would have your VMs within your vApp that would be self contained in it's networking L2 layer to avoid any reconfiguration etc, and you could deploy that setup multiple times having 1 specific setup for each developer for example.
The way you connect from the external network, into your org through either (Org Routed network, or Org Direct Network) is up to you.
I would need a networking diagram to help you further. (If you can give your typical setup for multiples environments, I'll help you through the process)
Hi Timo,
in attach you can find a typical network schema of a fenced configuration in Lab Manager.
In fact you can see:
at the top of the image (the pink square) the isolated network of our development VMs (the "Custom firewall" is the monowall) that route the network packets into a /24 network (static ip address) that is connected to the Service VM of Lab manager (the big gray roller is the builtin Lab Manager router that allow us to block or allow some particular VLAN or Port group).
This one route everything in our LAN (it uses DHCP in the 172.30.0.x/24 lan segment) and allow development guy to reach this isolated network. The monowall just readdress port requests.
(for example if I need to sqlplus to Oracle, I'll just connect to the 1521 port of the Native Lab Manager router IP address that will redirect my request to the monowall that will NAT & PAT me to the DB vm) from the LAN to the fenced configuration.
I hope I was clear.
Regards!
Hi timo,
did you have the time to have a look to my last post?
Dear Sender:
I will be on training by today returning to the office by tomorrow. Please expect delays in your email responding.
Regards
GR
Hi,
Just to clarify things on this diagram I have multiple questions :
In the "pink" area, I see the "User or Dev WKS" is this a VM that you want to duplicate in your "vApp" setup or is it something external (like a real physical laptop) ?
I'm asking because I see it in the "pink" area which is the Internal Virtual network "zone" in your diagram.
So are we having 3/4 VMs within your vApp (WKS, monowall, App, DB) ?
Another point bothering me in the diagram is the "native Lab manager router" having 2 nics on the same subnet (172.30.0.x/24), is this a copy/paste error ?
There are multiples ways of building a Dev vApp for your needs, and the simplest one that comes to mind is a vApp with a vApp Network, having (if you don't need different subnets for the "monowall" and the wks/app tier, 3 VMs configured statically, (WKS, App, DB), and then fenced to an Org Network. (using NAT or IP Translation, depending your needs externally)
That way once you add it to the catalog, and specify "make identical copy", you will be able to deploy multiple vApp with the exact same configuration for your developers, and they will just need to know the "external public IP" of their VMs (in case you are using IP translation) or the vShield Edge public IP (in the case you used NAT Port forwarding rules for Oracle / App for example).
Hope this helps,
