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

[Anna Redding < >]

Dominique / Ross,

Thank you both for your suggestions.

Until this point in time, I had not used the powerCLI software because "my" objective was to automate the VM buildout using Chef . So, I was trying to stick to code that worked as part of Chef and could run from a Chef Workstation running the Linux OS. 

But when I was unable to resolve the "vmdk add" issue at the end of last week, I started toying with replacing all my problematic 'knife vsphere' code with powerCLI code. But...my script is a unix shell script and powerCLI runs on windows OS so I then needed to figure out a way to remote execute the powerCLI code. 

Being new to Chef, I don't naturally think of referencing the gazillion gems that are out in the community so I did not realize there was a knife-windows plugin.  I found a utility called  winexe that looked promising. But, determined it to be problematic because I have to get authorization to install "every" piece of software as well as make any modifications that would allow remote execution. 

So, your suggestion of using the knife-windows gem was very timely...thank you!   Mostly, because of the fact that it is a 'ruby gem', and as such, I do not have to obtain authorization to load the code.  And, also, using it keeps me more in line with my 'Chef' objective. My problem is going to be whether we have authorization to make modifications to the windows config on our managed desktops (VDI) to allow remote execution. That will be the deal breaker and Ihope to know the answer to that tomorrow. 

Regarding knife-vsphere, I agree, I have three different bugs and I will work on submitting those next week. 

So again, thank you for the thought provokers, suggestions, and references to best practice/standards. They have all been most helpful.  

Now, if I can just get all this to work...wish me luck!!!

Anna

PS. A community member on this distro works for VMware and has offered to try and help me figurw oursee what's going on with the vcenter side of things

Senti from my iPhone

On Apr 8, 2014, at 4:12 AM, Dominique Poulain < "> > wrote:

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