[chef-dev] Re: [chef] Knife-vsphere vs powetCLI

[Dominique Poulain < >]

Hi Anna,

I'll second Ross, thanks for sharing your troubleshooting efforts; it's 
potentially very relevant and useful to all of us using Chef in combination 
with vSphere.

knife-vsphere is a separate project from Chef. As far as I know it doesn't 
have its own mailing list, but you can open an issue on GitHub:

https://github.com/ezrapagel/knife-vsphere/issues

You seem to have three different issues- one with vm clone, and two with vmdk 
add. There's an open issue about vmdk add 
(https://github.com/ezrapagel/knife-vsphere/issues/40), does it look like 
what you're running into when trying to attach a newly created vmdk to a VM?

As far as workarounds go, I'm afraid I can only echo what Ross wrote- would 
integrating PowerCLI with your build process be possible? The PowerCLI code 
could be run either using Chef on a Windows machine, as Ross suggested, or 
using knife ssh or knife winrm 
(http://docs.opscode.com/plugin_knife_windows.html) commands targeting a 
Windows machine in your build script. This is definitely kludgy, but could 
spare you the manual intervention until knife-vsphere is fixed.

HTH, and good luck :-)

dsp

On 8 Apr 2014, at 05:32, Ross Mohan 
<
 >
 wrote:

> Anna, 
> 
> Naive (or ignorant (or both)) question, perhaps, but....
> 
> If as you say <something> 'works no problem using powerCLI' any reason not 
> to wrap in an execute resource, or if needs be, roll-yer-own LWRP to do 
> same?
> 
> Thanks for sharing your work on this. I hope you keep doing so, 
> 
> -Ross
> ________________________________________
> From: Anna Redding 
> <
 >
> Sent: Monday, April 7, 2014 2:03 PM
> To: 
> 
 ;
>  
> 
 
> Subject: [chef] Knife-vsphere vs powetCLI
> 
> 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