chef/kitchen-vcenter

Support IPv4 assignment using DHCP

cattywampus opened this issue · 4 comments

cattywampus commented

Describe the Enhancement

This enhancement would add support to the guest customizations so that when a virtual machine is created it's IP address is assigned automatically using DHCP

Describe the Need

I'm working with a customer who has an immediate need for this feature to be supported before they are able to migrate away from the deprecated chef-provisioning-vsphere. I believe that this would be a valuable feature to many more users / customers who want to create kitchens in VCenter without having to manage static IP addresses manually in each of their kitchen configurations. Using the current fixed ip assignment, if two developers were trying to run kitchen in the same cookbook they would have to modify their configs to ensure the ip guest customizations don't conflict.

Current Alternative

At the moment the only way to manage IP address assignments to a VM is through its' assigned IP address using the guest customizations. I am not aware of a workaround to allow VM's to come up with automatic DHCP leased addresses.

Can We Help You Implement This?

The current implementation for guest customizations is great and I think it'll be easy enough to extend to support this feature. I'm going to take a swing at this tonight and see how far I get.

cattywampus commented

I started to work on this and decided it might be important to discuss this question before diving any deeper:

Should all of the guest customizations be required?

Currently if the guest_customization is not included in the kitchen configuration then the cloned VM won't contain any customized settings. This includes not being able to use DHCP and not having its' hostname set to be any different from the original template or vm. In my current implementation of adding DHCP support with the CustomizationDhcpIpGenerator I am debating on if this should continue to be the expectation.

From a user perspective, if I don't specify any settings I would want to have the virtual machine come up with some reasonable default configuration. Since no explicit IP address is specified (because Guest Customizations is omitted) then VMware should force the VM to at least attempt to obtain a DHCP lease if a server exists on the network. I would also assume that the hostname should reflect the name of the VM, helping to distinguish it from other kitchens / vm's when logged into them.

To support this the customization spec needs to be applied to the VM regardless if the guest_customization section is defined or not. Which means that the customization_spec method in the clone_vm.rb file should always return a RbVmomi::VIM::CustomizationSpec object. This in turn means that the validations used on the guest customization settings should not require each setting to be explicitly set. Perhaps some settings could have nil values or they could be defined with reasonable defaults. After reviewing how the deprecated chef-provisioning-vsphere gem handled these settings I think we could update the current guest customizations to follow this:

  • ip_address is optional. If provided it will be used to set the fixed IP address. If omitted the customization spec will fall back to using DHCP
  • subnet_mask is required only if the ip_address is specified. If the ip_address is omitted then DHCP will be used and the subnet_mask can be omitted
  • gateway is optional and if provided will only be used when assigning a fixed IP address. Maybe this be required if ip_address is specified?
  • dns_server_list is optional. If omitted the newly created vm would rely on any dns servers baked into the source vm / template
  • domain is optional. If omitted the newly created vm would default to whichever domain is baked into the source vm / template
  • dns_suffix_list is optional. If provided it will be used exactly as specified. If omitted it could default to the domain if that was provided, otherwise it would be blank / empty
  • timezone is optional and could probably default to UTC if it is omitted

This is a significant change from the current implementation so I would want to hear from the maintainers to discuss if any of this should be considered or if there are other ideas to explore.

thheinen commented

Machines use DHCP if there is no guest customization included, I don't get why this seems to be not working in your case?

Also, I have to object to make the customization mandatory (if I read your comment right?). So far, I have not had any need for it in several years for my usecases and have some pipelines which are geared towards maximum speed. That's why I built in things like Instant Clones. Some pipelines have their tests actually running within <10 seconds to give quick feedback. Customization makes things last at least 1-2 minutes longer if memory serves right from my tests. Especially Windows which seems to reboot at least once.

When looking into Guest Customization myself a few months back, I was a bit annoyed which of the parameters are actually required by the VMware API. We sadly can't just make some parameters optional, because the CustomizationSpecs would simply not be accepted by VMware then. Also, there is not one but three distinct customization methods (Linux, Windows and WindowsText) which have varying requirements. Summed up: it's a bit of a mess.

I would love proper customization support, if it is still an optional feature. This is also one of the increasing number of cases where I think the driver needs to be refactored into a minimalistic core, some bundled essential plugins and any externally developed plugins because the code is getting out of hand. I did some toying on a nice system including DSL and will try to look into that again.

cattywampus commented

Hi @tecracer-theinen - Thank you so much for your input. I'm very new to the VMWare API's so I'm still feeling my way around what's expected and how it should work. I'm actually having a hard time finding some good documentation on this so most of what I'm learning is coming from the code of the VSphere Ruby SDK, the deprecated chef-provisioning-vsphere gem, and the terraform-provider-vsphere plugin. If you have any other good resources that you could point me to I would greatly appreciate it, especially regarding the RbVmomi gem and the API it interacts with.

I originally implemented a basic form of supporting CustomizedIPSettings using DHCP instead of a Fixed IP and thought it would be useful if this customization spec could be applied without explicitly including the guest_customization section in the kitchen configuration. After reading your comments I did some experimenting and now I better understand some of the limitations about the required fields, especially with the CustomizationLinuxPrep object. It looks like out of all of the customization settings supported by this driver, the one RbVmomi absolutely can't work without is dns_domain. Given this it makes sense to dial back my original feature request to focus solely on the DHCP customized IP feature and leave the remaining guest customization settings as is.

Machines use DHCP if there is no guest customization included, I don't get why this seems to be not working in your case?

Yeah, that was my expectation when I started to test the kitchen-vcenter driver in my environment and has not been the case. Anytime I create a kitchen vm with this driver the only way it's able to get an address lease is if I log into it from the vSphere web UI and run dhclient from the command line of the VM. However once I modified my local copy of the driver code to use the RbVmomi::VIM::CustomizationDhcpIpGenerator object now my VM's are getting IP addresses every time. I poked around and discovered that both the chef-provisioning-vsphere gem and the terraform-provider-vsphere plugin both fall back to using this object if a static IP address isn't provided. So while I don't fully understand why this is necessary yet, based on my experience and how other developers/plugins are interacting with this API I think this is something that the kitchen-vcenter driver should support as well.

That's why I built in things like Instant Clones. Some pipelines have their tests actually running within <10 seconds to give quick feedback.

Wow! At the moment everything done on my project uses full clones but clearly I am going to have to try out instant clones. Currently doing a full clone in kitchen takes 3 minutes.

Given I've only approached this from the mindset of doing a full-clone I did not appreciate the impact that could happen with instant clones if customizations were required. I guess my intention was to try to (if possible) build the customization spec for the full clone regardless if the guest_customization was included in the kitchen config. This would at least ensure that full clones came up with custom hostnames and DHCP. However, based on what I learned (and commented on above) that the custom spec would require dns_domain to be a required parameter anyway for Linux.

I did some toying on a nice system including DSL and will try to look into that again.

I'm very invested in this plugin at the moment and would be interested in helping to expand on this with you. If there's anything I can do to help design, implementation, or testing let me know.

clintoncwolfe commented

Closing as implemented on #112