vApp in Catalog: Network Configuration problems at deployment using Static IP Pool

[ErikRaaijmakers]

Hi,

I'm currently doing an evaluation of VMware vCloud Director, in order to see if we can use that for self managed full automatic deployments of vApps by our customers. What we have currently installed and running as proof of concept: VMware products vCenter 5.0 on top of ESXi 4.1, vCloud Director 1.5 and vShield Manager 5.0.

I'm quite surprised by the behaviour when deploying a vApp in an organization cloud, and a virtual machine within the vApp is configured to get its IP address from the defined External Network Static IP pool. I experimented with several combinations, and it looks like I simply get confronted here with a bug? So here is the story:

The use case is that we have made a vApp containing at least one virtual machine that is configured to connect to the organization external network, and must take a free IP address from the External Network Static IP pool. We power on the vApp to see if it is working. And yes, it gets its IP address from the static pool. So far so good, we check if our vApp is working, and we power off the vApp.

Now we want to put that vApp in the organization Catalog, so that the end-users of that organization can deploy by themselves the vApp in their cloud. We have two options when putting the vApp in the Catalog:

1. Add to Catalog: "Make identical copy"
   
   When we deploy a couple of these vApp's in the organization cloud, then they still have kept their network configuration settings: the VM is connected to organization external network, IP mode is still "Static IP pool", BUT it still has kept the IP address from the initial vApp which was put in the catalog. So when powering on those deployed vApp's we get the conflict "IP address already in use". They do not take a free IP address from the static pool.
   
   We can tell the vCloud Director to reset the virtual machine MAC address (which gives a new MAC address), but that does not reset the IP address or give it back to the pool. Only way to get rid of it, is to set manually the IP address, or define DHCP. But we do not want that, we defined a static IP pool for the end users.
   
   Then maybe you would suggest to use the "Fence vApp" option in the network settings. So using Network Address Translation. In that case a vShield Edge virtual router is inserted in front of our vApp, and that virtual router takes itself 2 extra IP addresses from the static IP pool. Which is a waste, and a work-around solution for what we want. And actually it is possible to have applications that do not work behind NAT, because they need knowledge about their IP address on the outside.
   
   So then maybe you would suggest then the second option:
   
   
2. Add to Catalog: "Customize VM settings"
   
   Here indeed, when you deploy the vApp in your cloud, the vCloud Director enforces you to re-define its network configuration. The problem here, from end User eXperience point of view, is that ALL pre-defined network configuration settings of the vApp are simply gone. You have to specify again that it has to connect to the organization external network, that it should use static IP pool (instead of the other choices Manual IP and DHCP).
   
   It gets even worse when you have a vApp which contains a cluster of virtual machines with complete internal networks defined with predefined internal IP and MAC addresses, and among them one virtual machine which acts as the connector towards the outside organization network. When you deploy such a vApp in your cloud, you simply get a collection of virtual machines "lost in space" (or should we say "lost in cloud" ;-).
   
   All pre-defined network definitions are gone. As an end user, you will have to "repair" it and define them all over again.

So to my perception we have here the following issues/bugs:

• Issue 1: vApp in Catalog using external network Static Pool should not keep IP address from this pool:
  
  When a vApp is published in the catalog, and it uses a Static IP pool in its network configuration, then the IP address taken out from that IP pool should be removed. So the vApp available in the catalog should NOT have an IP address allocated to its network interface(s) using Static IP pool. When the vApp is deployed in the vCloud, then it should get its IP address from the Static IP pool (at deployment or power on). This is valid for both cases "Make identical copy" and "Customize VM settings".

• Issue 2: Customizeable vApp in Catalog should keep its default network configuration which can be changed at deployment in the cloud
  
  The option "Customize VM settings" means to me that you get a vApp with its default predefined network configuration, as it has been put in the catalog, and that you have the possibility to change and tweak this network configuration. NOT that everything is simply gone and that you have to do it all over again at every single deployment.

So what do you think? Do we have a bug here? Or is there something I overlooked (which is very well possible of course 🙂

Thanks already, with kind regards, Erik Raaijmakers

[bumj1]

Bringing this up as there is no solution posted and I am running in to the same issue.

Has anyone come up with a work around or solution to Issue 1.  I need to have the mac address reset and the IP address released back to the IP Pool when a vApp is added to the catalog when the "Make Identical Copy" option is selected.

[_morpheus_]

This was fixed in VCD 5.1

[bumj1]

Is this documented anywhere? I checked resolved issues in the release notes and did a knowledge base search and nothing turned up.  If it is documented somewhere and you could point me to it, that would be helpful.

Thanks

[_morpheus_]

I don't see this specific thing documented anywhere

[Cruroar]

I experience this behaviour in 5.1 as well.

[aneverov]

Hi all,

I believe you're facing some design limitation of the "Customize VM settings" mode which was still the case for 5.1

"Make identical copy" works as expected, since the idea is that captured VM must be exactly the same such that two instances can't co-exist while both powered on. That has its own use-cases like backup. Say you run some DB and configured all clients to its IP. Now you accidentally format hard-drive. But thanks to "identical" copy you can fix that very quickly - just instantiate, power-on and it will reply on same IP as before.

If you don't want that, you should be ideally using "Customize VM settings" mode. The problem is that, as you correctly pointed out, it throws away all networking topology settings.

I'm not aware of any good "automatic" workaround. Thing you may consider are:

1) use REST API which will allow you to pass additional sections for the "instantiate" call where you can provide networking setup

2) export OVF in the so called "loss-less" mode (was added in 5.1) which will produce OVF with network sections describing all details of the setup including topology, IP and MAC addresses. You may need to manually remove IP addresses from it, but maybe you can do without it - needs to be tested. The idea is to import back into VCD and UI (and REST API) may actually repopulate some of the networking info. Again needs to be tested. If it works, maybe this will be a better solution for you.

Hope that helps.

/Andrii

[bumj1]

Thanks for the response aneverov.

I work for a University and our use case is as follows:

A Faculty member creates a vApp to use in a lab for courses.  We want this vApp to be as generic as possible so that students can log in to vCloud Director and deploy this vApp in as few steps as possible.  We want to provide students access to the machines with as few steps as possible while also providing Facutly with the ability to create vApps and add them to the catalog for use by students.

I understand that we can use the API to automate some of this work, but in my use case, adding layers and customizations to our installation eliminates the self service features for Faculty and Student use. 

This may be something to consider for enhancements for future releases.

Thanks!