[chef] Knife-vsphere vs powetCLI

[Anna Redding < >]

As you've seen through several of my posts, I've been working on a project to 
clone and update a VM environment using Chef.  Due to the nature of the work, 
I have been using knife-vsphere as the means of accomplishing my objective. I 
have run into several 'nuances' and now a 'bug' that have plagued my 
progress. Interestingly enough, we can do this same process using powerCLI. 

Here's a summary of all the major issues I've encountered:

1). When cloning a VM using knife-vsphere , I cannot use a '-' as part of the 
VM name. This works with no problem using powerCLI. 

Note:   I had to invoke a 'bandaid' to get past this with knife-vsphere. 
Bandaid was to remove '-' from the vm hostname at the vsphere level. This 
bandaid is not 'desired' but is easily reverted with the manual effort,  
post-buildout, of going through and adding the '-' back to the hostname 
through the vcenter interface. 
Note2:  It's worth mentioning that the process of bootstrapping the vm and 
running cookbooks/recipes with VM names that contain '-' works just fine. 

2). When creating additional vmdk's for the VM, knife-vsphere cannot find the 
folder for the VM if the name of the VM is greater than 14characters.  This 
works with no problem using powerCLI.

Note1:  I had to invoke a 'bandaid' to get past this. Bandaid was to shorten 
the vm hostname at the vsphere level to 14 characters. This bandaid is not 
acceptable for our environment. The hostnames in this environment have up to 
20 characters. So, shortening the name means I have to write code to 
'migrate' the VM back to its correct name which is doable but problematic 
when editing the vmx files.  
Note2:  The process of bootstrapping the vm and running cookbooks/recipes 
with VM names greater than 14 characters works just fine. 
 
3). When creating additional VMDKs for the VM , knife-vsphere fails if you 
try to put the additional vmdk on the same datastore as the VM's primary 
vmdk. This works with no problem using powerCLI. 

Note: I tried to invoke a 'less than desirable ' bandaid to get past this but 
subsequent issues are occurring. The bandaid is to place 'each' additional 
vmdk's onto separate datastores. However, even though the code creates the 
vmdk, it fails to 'attach' the vmdk to the vm. So until that is resolved, 
this bandaid is a moot effort. 

4). When creating additional VMDKs for the VM and placing additional VMDKs 
onto a different datastore than the VM's primary vmdk, knife-vsphere creates 
the vmdk but fails when it tries to attach the addon vmdk to the VM. This 
works with no problem using powerCLI.

5). When creating additional VMDKs for the VM and placing additional VMDKs 
onto a different datastore than the VM's primary vmdk, knife-vsphere creates 
the vmdk but if you try to create another vmdk on the same datastore as the 
first addon vmdk, it fails because the folder for the VM where the vmdk is 
stored already exists (same as #2 but with addon vmdk's). This works with no 
problem using powerCLI.

So my original objective for this project was to automate the process of 
building out an environment of VMs using Chef with little or no manual 
intervention. 
At this point, the conclusion I must provide leadership is that, due to the 
aforementioned issues, we cannot do this. 

We must use powerCLI, as opposed to knife-vsphere, to buildout the VM's.  
Once the vm is built, we can then bootstrap the VM to the chef server, 
complete the buildout, and provide ongoing management using chef.  This does 
not meet my original objective but at this point looks like the only answer 
unless I can get resolution to the aforementioned issues, particularly those 
associated with the  addon VMDKs. 

I do appreciate everyone's help and patience as I struggled through the 
learning curve for this. I wanted to make sure I summarized all the issues 
and maybe obtain some guidance as to whether I should open a bug report (and 
where to do that). 

Thanks again. Have a great day. 
Anna


Sent from my iPhone