Project

General

Profile

Bug #7740

Installing from VMware Image breaks distributed Port Group support

Added by Felix Kellner almost 6 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Compute resources - VMware
Target version:
Difficulty:
Triaged:
Bugzilla link:
Pull request:
Fixed in Releases:
Found in Releases:

Description

I have a setup running a distributed vSwitch between two ESXi clusters. This distributed vSwitch runs two distributed port groups: "Intranet" and "Provision". No other ("normal") networks, switches, etc. exist at all in my vSphere.

Upon creating a new host in Foreman, I see the following three entries: dvSwitchProd-DVUplinks, Intranet, Provision

1. Selecting the "Provision" distributed port group, an image based operating system and NOT selecting any image (i.e. not having any image set up in the first place), the host gets set up with the correct "Provision" distributed port group. This worked several times.

2. Selecting the "Provision" distributed port group, an image based operating system and also selecting an image I prepared, the host gets set up with a normal, non-existant "Provision" network. The initial state in vSphere is "disconnected" and trying to connect it results in the following error: "Failed to connect virtual device ethernet0."

3. Even after deleting this image and redoing exactly what worked in the first step, I get the same result as in step 2.

Note: Since my vSphere is running on a German version of Windows, I'm also affected by Bug #5630 which I got around using a regex version of http://projects.theforeman.org/issues/5630#note-4. This just as a note, as I'm unware whether this could also be a reason for my problem. (seeing that my image was created with a German version of vSphere)


Related issues

Related to Foreman - Bug #5630: VmWare clone from template fails if Network Adator has labels in VmWareClosed2014-05-08
Related to Foreman - Bug #5483: Network label empty after cloning vware vm using image and distributed switch for networkClosed2014-04-29
Blocked by Foreman - Refactor #9982: Update fog to 1.29.0Closed2015-04-01

History

#1 Updated by Friedrich Seifts almost 6 years ago

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

#2 Updated by Felix Kellner almost 6 years ago

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.

#3 Updated by Friedrich Seifts almost 6 years ago

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

#4 Updated by Friedrich Seifts almost 6 years ago

I reverted the template back to a VMX9 version to use the thick client. It looks like Foreman is deploying the VM from the template, but its tagging the network port group as a "standard port group" not a "distributed port group"

#5 Updated by Friedrich Seifts almost 6 years ago

  • Related to Bug #5630: VmWare clone from template fails if Network Adator has labels in VmWare added

#6 Updated by Byron Miller over 5 years ago

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.

#7 Updated by Magnus Glantz over 5 years ago

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

#8 Updated by Dominic Cleal over 5 years ago

  • Related to Bug #5483: Network label empty after cloning vware vm using image and distributed switch for network added

#9 Updated by Chris Pisano over 5 years ago

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

#10 Updated by Dominic Cleal over 5 years ago

#11 Updated by Dominic Cleal over 5 years ago

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.

#12 Updated by Chris Pisano over 5 years ago

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.

#13 Updated by Francois Herbert over 5 years ago

Hi Chris

See #10087 for your last issue.

#14 Updated by Dominic Cleal over 5 years ago

  • Status changed from New to Closed
  • Legacy Backlogs Release (now unused) set to 50

Marked for 1.8.1 along with the Fog 1.29.0 update, this should be fixed in current nightlies too.

Also available in: Atom PDF