uploading box hangs

[StefanScherer]

I try your precise32 box to upload to our vCloud server. My first tests I have done on a windows box. Currently I am trying from an Ubuntu box, but both with vagrant 1.4.3 and vagrant-vcloud 0.1.1.

I have removed the test catalog from vCloud and called

vagrant up --provider=vcloud

But when uploading the box it seems to hang until a timeout (60 minutes) aborts it.

Now I have retried with debug logging of vagrant and put the output into this gist https://gist.github.com/StefanScherer/8729608

In vCloud web gui I only see that the import of precise32 is at 1%.

Is there anything I could try to make this work? I am just using the Vagrantfile example of your README.md file, but only with one box web-vm in the nodes array.

[StefanScherer]

I have drilled down the problem a little further by modifying version_5_1.rb file as follows:

        @logger.debug("Waiting for the upload links to show up in the vAppTemplate we just created.")
        while true
          response, headers = send_request(params)
          @logger.debug("Request...")
          @logger.debug(params)
          @logger.debug("Response")
          @logger.debug(response)
          @logger.debug(headers)
          break unless response.css("Files Link [rel='upload:default']").count == 1
          sleep 1
        end

Then I tried the upload again and catched the output in this gist: https://gist.github.com/StefanScherer/8732578

I should write the debug output as plain xml, I think. I do not code ruby, if you have a hint I could improve the debugging.

It seems that the loop does not terminate although it seems to me that the precise32 box is shown in the response from the vcloud server.

[tsugliani]

Hi @StefanScherer,

I'll add some debug code to help us identify what is going wrong. I'm currently busy & traveling so expect some delays.

Thanks,

[StefanScherer]

Thalia for the reply. In the meantime I tried to break the loop After some seconds, but then some filename for the description.ovf is built with some Parts of the URL including http://ipaddress so the absolute path is wrong.

But I know now that I should have written response.to_xml for the debug output.

Any short tip to start vagrant ruby scripts within a debugger to watch the variables?

[tsugliani]

Can you check that vCloud Director is correctly configured ?

I did an old blog post about something that could be your issue here : http://blog.tsugliani.fr/featured/vcloud-director-common-issue-cant-upload/

Let me know if this helps,

[StefanScherer]

I will discuss this with our sysops. Thanks for the link. Our Installation is still very fresh and we had a Networking issue within the VMs today where even a VMware told that he had never seen this before, I think that will help us.

[avullo]

Hello Stefan,

I've stumbled upon the same problem. Did you manage to get your way through it?

[avullo]

As a side note,

I've tried to isolate the problem, running the same upload operation this time using the vCloud REST API. Again, same problem. After uploading, I receive a response 200 which indicates that the request was valid and is being processed. Then I retrieve the VAppTemplate to verify that the OVF descriptor is uploaded. I could see the number of bytes transferred matches the size of the descriptor, but the value of the template's ovfDescriptorUploaded attribute is not set to true, which prevents the entire operation to proceed.

[StefanScherer]

Hello Allesandro,

in the meantime I tried to upload the vmx by using ovftool and a small PowerCLI Script. But we still have upload problems. The upload jumps from 51% back to some 30% and so on. We have to get this fixed first. I will let you know if I know more.

Stefan

Am 03.03.2014 um 11:06 schrieb Alessandro Vullo notifications@github.com:

Hello Stefan,

I've stumbled upon the same problem. Did you manage to get your way through it?

— Reply to this email directly or view it on GitHub.

[frapposelli]

Can you guys confirm if the upload via web UI works? otherwise could be a VCD configuration problem.

[StefanScherer]

Yes, the upload via Web UI does work. That's our workaround at the moment. For now we just create Base boxes with packer.

Stefan

Am 03.03.2014 um 12:12 schrieb Fabio Rapposelli notifications@github.com:

Can you guys confirm if the upload via web UI works? otherwise could be a VCD configuration problem.

— Reply to this email directly or view it on GitHub.

[avullo]

Thanks Stefan and Fabio.

I'm currently working with my sys admin to see if it's a configuration problem. It works for him after updating the public REST URL but, similarly to Stefan, I'm still having issues.

[avullo]

Hi,

I've finally been able to talk to my sysadmin. This is his explanation on the state of affairs: "I'm afraid we don't upload templates using the API, we generally create them on the vcloud interface itself or import them from the vsphere layer"

Then he continues: "You could try using one of the existing templates in the vcloud environment, or modifying one to suit your needs. You could manually create a VM from one of the existing templates, modify it, create your own template, then use vagrant to create VMs from it. That way you would avoid uploading a template."

Ok, but then I'm left with the question: how do I use vagrant to create VMs from templates on vCloud? My experiments with the plugin suggested that the command: $ vagrant up --provider=vcloud

brings up and eventually provision a VM from a box which is specified in the Vagrantfile. What I've seen is that vagrant attempts to upload to vCloud the unpacked box file which contains the OVF, metadata.josn, the manifest file and the vmdk disks.

[frapposelli]

@avullo you can trick vagrant-vcloud by creating an empty box that has the same name as a template that is already in the catalog, upon first call vagrant will import the empty box and will simply skip the upload part as the template is already present in the catalog.

It's suboptimal but if you're not allowed to import your own vApps it's the only way to consume vCloud resources using Vagrant.

[StefanScherer]

My sysadmin tried another way to upload the OVF to vCloud. At this time using the ovftool itself. We struggled with powercli scripts, as I mentioned earlier.

ovftool sample.ovf "vcloud://upload:XXXXXXX@YOUR_VCLOUD_SERVER:443?org=YOUR_ORG&vappTemplate=testtemplate&catalog=YOUR_CATALOG&vdc=YOUR_VDC"

See also: http://vcdx56.com/2013/11/07/ovf-tool-to-upload-ova-files-to-vcloud-director/

[StefanScherer]

May be a little off topic, but at the moment we start to fill our vCloud with base boxes built with packer. Afterwards we upload them now with the ovftool.

I had a look at the packer sources:

• docs - http://www.packer.io/docs/post-processors/vsphere.html
• sources - https://github.com/mitchellh/packer/blob/master/post-processor/vsphere/post-processor.go

The vSphere post-processor builds a "vi://" url instead of the "vcloud://" url. So it may helpful to have a vCloud post-processor built into packer.

But still also I want to use Vagrant with the vCloud, but this may move the upload problem away from vagrant if we use templates already uploaded into vCloud.

I will try the empty box trick in the next days.

[avullo]

Hi Fabio, thanks for the info.

Indeed, I've managed to do what you've suggested and trick the plug-in, nice! But then I get the error (400 Bad Request (Runtime Error)) reported here: https://gist.github.com/avullo/9504393 (file: vagrant-vcloud_out.txt) I also include the Vagrantfile I use in this particular case (I have a template called starman on vCloud with the same name as the dummy box).

From Director, I can see a vApp has been built with name Vagrant-$USER-$HOSTNAME-xxxxxxx which has a network configuration which I don't expect. I would expect the vApp to be directly connected to the org vDC network 'ensembl-test-net' (gateway 192.168.2.1). The plug-in instead creates a vApp network 'Vagrant-vApp-net' with gateway 10.1.1.1 which connects to 'ensembl-test-net' with NAT routing.

What in your opinion could be done in order to successfully proceed with creating/provisioning the template VM?

[tsugliani]

Hi @avullo and @StefanScherer,

@StefanScherer if you can upload using ovftool, then your vCloud Director setup should be fine. I really need to get more debug information, and the current code on "develop" branch on vagrant-vcloud does permit a much higher/verbose debug output, would it be possible for you to checkout the vagrant-vcloud repository, switch to the "develop" branch, generates the vagrant-vcloud gem and test it to gives us much more debug ? Assuming you are on linux or Mac OS X

1. mkdir -pv $HOME/tmp/vagrant-debug && cd $HOME/tmp/vagrant-debug
2. git clone https://github.com/frapposelli/vagrant-vcloud.git && cd vagrant-vcloud
3. git checkout develop
4. gem build vagrant-vcloud.gemspec
5. vagrant plugin uninstall vagrant-vcloud
6. vagrant plugin install vagrant-vcloud-0.2.0.gem

then if possible clean everything on vcloud-director, and launch the debug command again using your Vagrantfile:

VAGRANT_LOG=DEBUG vagrant up --provider=vcloud

This should output a pretty heavy debug, at least every created/received XML answer/response and REST verb & URL that would be greatly valued for our troubleshooting. (If you want to avoid any delicate information showing, clean it beforehand, or send me directly an email)

About Packer, we might look into it at some point, but first let's try to fix those issues :-)

@avullo I see that you are using an internal IP for a public vCloud Director instance accessible on internet in your Vagrantfile, which surprises me a bit.

vcloud.vdc_edge_gateway_ip = "192.168.2.1"

I would expect a public IP here, from your sub allocated pool on the Edge GW below:

vcloud.vdc_edge_gateway = "ensembl-test-edge"

What you see for the vApp & network configuration is expected, it will create a vApp Network with an internal subnet (the 10.1.1.0/24), and this will be NATed into the vApp to keep everything controlled within the vApp container and not need to rely on anything else externally for ease of management, and will create automatically the according network port forwarding rules to reach your VMs. (This avoids wasting public IPs, which are pretty expensive these days, hope this makes sense)

Would it be possible for you to create/share an account on that vCloud Director instance with us ? That would help greatly for troubleshooting, if I could try to use your Vagrantfile against it and see fix the issues when I face them. Of course this might not be possible, but if it is, let me know by email :-)

If not, can you try the same steps as @StefanScherer by updating to our current debug code on the develop branch of this repository to get some extensive debug logs ?

Thanks in advance,

[StefanScherer]

Hello @tsugliani,

yes, upload with ovftool does work (at least ovftool version 3.5.0, the 3.0.2 of VMware Workstation 10 seems to crash). I have tested it again. Our vCloud was 'cloudless' last week, so I could not test anything, but it should be ok now. So I could try building the vagrant plugin as you described. Unfortunately I'm on Windows which makes every step harder, I know. But with every step I learn and that's fun.

In the meantime I started a PR for packer to have a vCloud post-processor. I also learned to build Go sources, and built me a Go cross compiler box first to make it reproducible for me and others. With this Ubuntu box I am able to build the windows exe files (you know my handicap) and tested these some hours ago with the first uploads. If this really works fine, I will send the PR to Mitch to integrate it into packer 0.5.x. You may also have a look at it if you want.

[StefanScherer]

I have tried to build the develop version of the plugin. First on my Mac and copied the vagrant-plugin-0.2.0.gem as you described and then copied to the work PC. After installing the plugin, there is an error loading the plugin. I uninstalled it again, and tried to build it on the PC with the embedded ruby of vagrant:

1. set PATH=%PATH%;c:\hashicorp\vagrant\embedded\bin
2. gem build vagrant-vcloud.gemspec
3. vagrant plugin uninstall vagrant-vcloud
4. vagrant plugin install vagrant-vcloud-0.2.0.gem
5. set VAGRANT_LOG=debug
6. vagrant up --provider=vcloud

But there still is an error.

 INFO environment: Loading plugin from JSON: vagrant-vcloud
ERROR root: Failed to load plugin: vagrant-vcloud
ERROR root:  -- Error: #<Gem::LoadError: Unable to activate vagrant-vcloud-0.2.0, because nokogiri-1.6.1-x86-mingw32 conflicts with nokogiri (~> 1.5.5)>
ERROR root:  -- Backtrace:
ERROR root: C:/HashiCorp/Vagrant/embedded/lib/ruby/2.0.0/rubygems/specification.rb:2007:in `raise_if_conflicts'
C:/HashiCorp/Vagrant/embedded/lib/ruby/2.0.0/rubygems/specification.rb:1176:in `activate'

I have installed Vagrant 1.4.3 on the PC. I am not familiar with Ruby at the moment. But to get out of the windows host trouble, I will build a clean Linux box to build and test the vagrant plugin.

[frapposelli]

@StefanScherer the problem on your windows machine is that you still have the old nokogiri plugin which is at a later version than the one we require today (the downgrade was done due to an upstream bug).

To successfully install the plugin you need to remove the nokogiri-1.6.1-x86-mingw32 from the gems in your .vagrant.d folder (should be under your user directory) and try the install again.

HTH, Fabio

[StefanScherer]

@frapposelli Thanks! Yes, the develop plugin is now installed. Now I can do more tests.

I found one minor problem. In my Vagrantfile, I use the FQDN of our vCloud server,

      vcloud.hostname = "https://roecloud001.sealsystems.local"

but it seems that our admins has configured the global URL which you told me some weeks ago has just the server name, propably https://roecloud001. The vagrant-vcloud plugin then is disturbed and tries to prepend the whole value from the Vagrantfile in front of the URL given from the vCloud server.

b:\GitHub\basebox-slave\test\precise32 [master]>vagrant up --provider=vcloud 2
>vagrant-debug7-stderr.log
Bringing machine 'web-vm' up with 'vcloud' provider...
"SEND https://roecloud001.windomain.local/api/sessions"
"RECV 200"
<?xml version="1.0" encoding="UTF-8"?>
<Session xmlns="http://www.vmware.com/vcloud/v1.5" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" user="vagrant" org="SS" type="application/vnd.vmware.vcloud.session+xml" href="https://roecloud001/api/session/" xsi:schemaLocation="http://www.vmware.
com/vcloud/v1.5 http://roecloud001/api/v1.5/schema/master.xsd">
    <Link rel="down" type="application/vnd.vmware.vcloud.orgList+xml" href="https://roecloud001/api/org/"/>
    <Link rel="remove" href="https://roecloud001/api/session/"/>
    <Link rel="down" type="application/vnd.vmware.admin.vcloud+xml" href="https://roecloud001/api/admin/"/>
    <Link rel="down" type="application/vnd.vmware.vcloud.org+xml" name="SS" href="https://roecloud001/api/org/14f84887-ef1c-4009-a333-0904bdcaf49e"/>
    <Link rel="down" type="application/vnd.vmware.vcloud.query.queryList+xml" href="https://roecloud001/api/query"/>
    <Link rel="entityResolver" type="application/vnd.vmware.vcloud.entity+xml" href="https://roecloud001/api/entity/"/>
    <Link rel="down:extensibility" type="application/vnd.vmware.vcloud.apiextensibility+xml" href="https://roecloud001/api/extensibility"/>
</Session>
"SEND https://roecloud001.windomain.local/api/org"
"RECV 200"
<?xml version="1.0" encoding="UTF-8"?>
<OrgList xmlns="http://www.vmware.com/vcloud/v1.5" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" type="application/vnd.vmware.vcloud.orgList+xml" href="https://roecloud001/api/org/" xsi:schemaLocation="http://www.vmware.com/vcloud/v1.5 http://roecl
oud001/api/v1.5/schema/master.xsd">
    <Org type="application/vnd.vmware.vcloud.org+xml" name="SS" href="https://roecloud001/api/org/14f84887-ef1c-4009-a333-0904bdcaf49e"/>
</OrgList>
"SEND https://roecloud001.windomain.local/api/org/https://roecloud001/api/org/14f84887-ef1c-4009-a333-0904bdcaf49e"

Is there a way to fix this in the plugin code? But I will fix my Vagrantfile for now, but I want to mention it if others also may have problems.

[tsugliani]

Hi @StefanScherer,

Hmm ok, I see what's going on, and that's not going to work out well.

From what I see you have vcloud.hostname = "https://roecloud001.windomain.local"in your Vagrantfile and not vcloud.hostname = "https://roecloud001.sealsystems.local", and in your vCloud Director configuration you have for sure only the short hostname which is bad (https://roecloud001as you described)

You should have your full FQDN hostname in the vCloud Director Public REST API setup as I wrote about it here: http://blog.tsugliani.fr/featured/vcloud-director-common-issue-cant-upload/ (In my case it's https://vcloud.tsugliani.fr)

Basically what you see in the vCloud Director UI for the public REST API url should match EXACTLY what you have on the vcloud.hostname Vagrantfile provider configuration.

Everything is based on that default api URL, which should be correct at all times.(Basically we forge the first step of creating the request URL to connect and talk with the API, but afterwards everything is returned by the vCloud API, concatenating the default "configured" API URL from the UI setting I've wrote about on my blog post, and the object namespaces, and we do basically substitutions between them)

To bypass this issue for now, you can probably put vcloud.hostname = "https://roecloud001" in your Vagrantfile and make sure that your computer can resolve that short hostname correctly.

Hope this helps and makes sense,

Thanks for the feedback !

[StefanScherer]

Sorry, I got a typo in my last comment. I had the same FQDN in both stdout and the Vagrantfile.

And after using the SAME value in my Vagrantfile as in the current configuration of our vCloud Director, I got many many XML output, but hey, the Upload of your precise32 box worked and the vApp is up and running.

Using this Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :

precise32_vm_box_url = "http://vagrant.tsugliani.fr/precise32.box"

nodes = [
  { :hostname => "web-vm",  :box => "precise32", :box_url => precise32_vm_box_url }
]

Vagrant.configure("2") do |config|

  nodes.each do |node|
    config.vm.define node[:hostname] do |node_config|
      node_config.vm.box = node[:box]
      node_config.vm.hostname = node[:hostname]
      node_config.vm.box_url = node[:box_url]
      node_config.vm.network :forwarded_port, guest: 80, host: 8080, auto_correct: true
      # node_config.vm.provision :puppet do |puppet|
      #   puppet.manifests_path = 'puppet/manifests'
      #   puppet.manifest_file = 'site.pp'
      #   puppet.module_path = 'puppet/modules'
      # end
    end
  end
end

I now have the "web-vm login:" prompt. This is a really breakthrough. Many thanks! I will tell my admin to fix the URL to the FQDN and then I correct my Vagrantfile. This will be the better solution.

[tsugliani]

Hi @StefanScherer

That's very good news ! (I'm not going to lie, and I have only tried my vagrant box in my tests right now, because I built it specifically for vCloud Director, so if you have upload issues with your box, could you share it with me, privately if needed, so I can try to understand what's wrong ?)

We still have lot of work to do on it, but we hope to make it better as we progress over time. (At least with the upcoming 0.2.0 version it should be much easier for us to understand what's going on with the extensive xml debug logs I've added)

Thanks !

[StefanScherer]

I will keep in the develop branch. Tomorrow I with a bigger windows box, because we had problems uploading bigger ovfs. I will compare your vcloud precise32 box and how I should modify a VMware based Box.

[frapposelli]

Just a heads up, we just released version v0.2.1 12f590e1edb7ee252a9905c830438c3a2721f24c that introduces many bugfixes and the new verbose debug.

[StefanScherer]

Thanks! I'm already watching your project, so I got your release infos. Thanks in advance for your effort. I could not do any more tests since because of other projects, but I will update the plugin very soon!

[avullo]

Thanks Fabio,

I've just updated the plugin, and it's not working any more:

/home/avullo/.vagrant.d/gems/gems/vagrant-vcloud-0.2.1/lib/vagrant-vcloud/action.rb:187:in `block (2 levels) in action_up': uninitialized constant VagrantPlugins::VCloud::Action::HandleBox (NameError)

Can I get 0.2.0 back meanwhile?

thanks

[frapposelli]

@avullo that comes from vagrant, try to update to a more recent version. HandleBoxUrl was deprecated and we switched to the new syntax on 0.2.x.

[avullo]

thanks, back on track now :)

[StefanScherer]

So, I ran a test with the vagrant-vcloud 0.2.1 from a windows machine. I only installed Vagrant 1.5.2 with the vagrant-vcloud 0.2.1 plugin. I tested the upload, it works fine with the precise32.box. But I encounter a problem with the NAT rules. I have attached all debug output here: https://gist.github.com/StefanScherer/10015870 Is it ok for you to write the stdout and stderr into two different files? I have made a simple bat script to call vagrant with --debug option and output redirection.

This is the output without the --debug option:

C:\Users\vagrant\code\basebox-slave\test\precise32>vagrant up
Bringing machine 'web-vm' up with 'vcloud' provider...
==> web-vm: Booting VM...
==> web-vm: Removing NAT rules on [SS-EDGE] for IP [10.100.52.4].
C:/Users/vagrant/.vagrant.d/gems/gems/vagrant-vcloud-0.2.1/lib/vagrant-vcloud/driver/base.rb:329:in `send_request': Warning: unattended code 500 Server Error (RuntimeError)
        from C:/Users/vagrant/.vagrant.d/gems/gems/vagrant-vcloud-0.2.1/lib/vagrant-vcloud/driver/version_5_1.rb:1149:in `find_edge_gateway_id'
        from C:/Users/vagrant/.vagrant.d/gems/gems/vagrant-vcloud-0.2.1/lib/vagrant-vcloud/driver/version_5_1.rb:1487:in `remove_edge_gateway_rules'
        from C:/Users/vagrant/.vagrant.d/gems/gems/vagrant-vcloud-0.2.1/lib/vagrant-vcloud/action/power_on.rb:52:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/builder.rb:116:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/runner.rb:69:in `block in run'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/util/busy.rb:19:in `busy'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/runner.rb:69:in `run'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/builtin/call.rb:51:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/builder.rb:116:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/runner.rb:69:in `block in run'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/util/busy.rb:19:in `busy'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/runner.rb:69:in `run'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/builtin/call.rb:51:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/warden.rb:34:in `call'
        from C:/Users/vagrant/.vagrant.d/gems/gems/vagrant-vcloud-0.2.1/lib/vagrant-vcloud/action/connect_vcloud.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/builtin/call.rb:57:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/warden.rb:34:in `call'
        from C:/Users/vagrant/.vagrant.d/gems/gems/vagrant-vcloud-0.2.1/lib/vagrant-vcloud/action/connect_vcloud.rb:50:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/builtin/call.rb:57:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/builder.rb:116:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/runner.rb:69:in `block in run'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/util/busy.rb:19:in `busy'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/runner.rb:69:in `run'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/machine.rb:157:in `action'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/batch_action.rb:72:in `block (2 levels) in run'

C:\Users\vagrant\code\basebox-slave\test\precise32>

Is it a misconfiguration, wrong IP of my edge gateway, too few access rights?

[frapposelli]

This is an interesting one, would you care opening a new issue so we can track it separately? looks like there's an issue with handling a variable, can you please try and use a single Vagrantfile instead of sourcing a global and a specific one? I think that is the culprit.

[tsugliani]

Hi @StefanScherer,

Can you let us know what permissions/role does your vCloud Director user have ?

Thanks,

[StefanScherer]

Sure, this one is off topic. Should we close now this ticket? Upload seems to work. I have asked our sysadmin. It seems my account does not have permissions to make NAT rules from outside of the vCloud into my vDC. But I also had a config error, my IP of the edge gateway is wrong. I will do more tests and ask for more details of my permissions.

[tsugliani]

Hi @StefanScherer,

We will take care of closing it, Be sure to create a new one so that we can follow/track this issue properly :-)

Thanks,

[StefanScherer]

I have replayed my error and created #33.