I'm having the same exact problem, except I'm not a German Locale install. It is EN based.

I have a vmware template that I deploy from using Foreman. Foreman can see all my existing VM's, datacenters, Virtual dist. switches and port groups.

When Foreman deploys the a VM from the templates, it successfully puts that VM on the correct dist port-group, but the adapter is in a "disconnected" state. When I try to put the adapter in the connected state a error is returned " Failed to connect virtual device ethernet0". Now, within the VMWARE web ui, If i put the adapter on a different dist. port group, I can then 'connect' the adapter with no errors, and then , even more strange, I can put the adapter back onto the original dist. port group and it remains connected and the VM has IP connectivity.

Needless to say this is a showstopper for our Foreman en devour, have you had any luck sorting this?

Vcenter 5.5U1
Foreman 1.6.1

In my case it doesn't even connect to a distributed port group in the first place, it simply creates it as a non-distributed network connection and therefore obviously can't get a connection.

I'm currently in fact using network provisioning with VMware instead of image based provisioning due to this problem.

Here is what the production.log shows when doing the VM deploy:

Started POST "/hosts" for 10.4.7.39 at 2014-11-12 08:46:51 -0500
Processing by HostsController#create as /*
Parameters: {"utf8"=>"✓", "authenticity_token"=>"XXXXXXXXXXXX", "host"=>{"name"=>"nictest1", "hostgroup_id"=>"", "compute_resource_id"=>"1", "compute_profile_id"=>"4", "environment_id"=>"1", "puppet_ca_proxy_id"=>"", "puppet_proxy_id"=>"", "puppetclass_ids"=>[""], "managed"=>"true", "progress_report_id"=>"[FILTERED]", "type"=>"Host::Managed", "compute_attributes"=>{"cpus"=>"1", "corespersocket"=>"1", "memory_mb"=>"1024", "cluster"=>"ucs01.web2.prod.lipsum.net", "path"=>"/Datacenters/WEB2/vm/Discovered virtual machine", "guest_id"=>"centos64Guest", "hardware_version"=>"vmx-10", "interfaces_attributes"=>{"new_interfaces"=>{"type"=>"VirtualE1000", "network"=>"dvportgroup-322", "_delete"=>""}, "0"=>{"type"=>"VirtualVmxnet3", "network"=>"dvportgroup-317", "_delete"=>"1"}, "new_1415799971496"=>{"type"=>"VirtualVmxnet3", "network"=>"dvportgroup-322", "_delete"=>""}}, "volumes_attributes"=>{"new_volumes"=>{"datastore"=>"vmax-prod-lun1", "name"=>"Hard disk", "size_gb"=>"10", "thin"=>"true", "eager_zero"=>"false", "_delete"=>""}, "0"=>{"datastore"=>"vmax-prod-lun1", "name"=>"Hard disk", "size_gb"=>"10", "thin"=>"true", "eager_zero"=>"false", "_delete"=>""}}, "scsi_controller_type"=>"VirtualLsiLogicController", "start"=>"1", "image_id"=>"baselines/centos/6.5/c1.m1.vcenterha"}, "domain_id"=>"5", "realm_id"=>"", "mac"=>"", "subnet_id"=>"2", "ip"=>"10.55.29.252", "interfaces_attributes"=>{"new_interfaces"=>{"_destroy"=>"false", "type"=>"Nic::Managed", "mac"=>"", "name"=>"", "domain_id"=>"", "ip"=>"", "provider"=>"IPMI"}}, "architecture_id"=>"1", "operatingsystem_id"=>"2", "provision_method"=>"image", "build"=>"1", "ptable_id"=>"", "disk"=>"", "root_pass"=>"[FILTERED]", "is_owned_by"=>"4-Users", "enabled"=>"1", "model_id"=>"", "comment"=>"", "overwrite"=>"false"}, "capabilities"=>"build image", "provider"=>"Vmware"}
User Load (0.2ms) SELECT "users". FROM "users" WHERE "users"."id" = $1 LIMIT 1 "id", 4

I see the same issue with 1.7.2 today, the adaptor comes up offline and i have to go into vsphere and remove/add or click on the enable and save once or twice to get it to show up.

I've also hit this issue. When deploying from template vm_clone.rb does not handle Distributed Port Groups and re-creates one NIC as Standard Port Group (without a label).
A side note: vm_clone.rb does neither handle multiple NICs. It handles only one NIC atm.

The only work-around I've found is to set the NICs correct in the VMware template, and then disable the network related code in vm_clone.rb. That will create a VMware guest with correct NICs (as long as they where correct in the template from the start).

Hash off the following code in vm_clone.rb for this:

          #if ( options.has_key?('network_label') )
          #  #network_obj = datacenter_obj.networkFolder.find(options['network_label'])
          #  config_spec_operation = RbVmomi::VIM::VirtualDeviceConfigSpecOperation('edit')
          #  nic_backing_info = RbVmomi::VIM::VirtualEthernetCardNetworkBackingInfo(:deviceName => options['network_label'])
          #    #:deviceName => "Network adapter 1",
          #    #:network => network_obj)
          #  connectable = RbVmomi::VIM::VirtualDeviceConnectInfo(
          #    :allowGuestControl => true,
          #    :connected => true,
          #    :startConnected => true)
          #  device = RbVmomi::VIM::VirtualE1000(
          #    :backing => nic_backing_info,
          #    :deviceInfo => RbVmomi::VIM::Description(:label => "Network adapter 1", :summary => options['network_label']),
          #    :key => options['network_adapter_device_key'],
          #    :connectable => connectable)
          #  device_spec = RbVmomi::VIM::VirtualDeviceConfigSpec(
          #    :operation => config_spec_operation,
          #    :device => device)
          #  virtual_machine_config_spec.deviceChange = [device_spec]
          #end

using the vm_clone.rb from the below link seems to have fixed the issue for me.

https://github.com/fog/fog/blob/master/lib/fog/vsphere/requests/compute/vm_clone.rb

Nice find Chris. It looks like this fixes it: https://github.com/fog/fog/commit/00425b6c1705287533658a45400d78807f24fc94

When the next version of Fog is released, we should get this fixed via #9982. Depending on the risk, that may be 1.9 rather than a 1.8.x update, but we'll see closer to the time.

Thanks Dominic. That would be a huge fix. Once I got this issue resolved though I noticed that even if I selected VMXNET3 as the NIC, Foreman provisioned the new host with an E1000 NIC. I tried this patch https://github.com/fog/fog/commit/7fa1873faace8c730434ed3d39251db8184c7131 but as you can see by my comment it broke my virtual machine tab on the new host page.

Hi Chris

See #10087 for your last issue.