Knife-vsphere vs powetCLI


#1

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


#2

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.

FWIW I have never had this issue in my environment with knife-vsphere
when cloning templates and VMs. In fact 90% of our VM names contain a
’-’.

//ian


#3

Thanks for letting me know.

What version of the following are you using?
- vCenter ; ESXi
- Chef server ; Chef client
- Ruby ; knife-vsphere gem

Sent from my iPhone

On Apr 9, 2014, at 4:00 PM, Ian Delahorne ian.delahorne@gmail.com wrote:

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.

FWIW I have never had this issue in my environment with knife-vsphere
when cloning templates and VMs. In fact 90% of our VM names contain a
’-’.

//ian


#4

Also to note: I wrote and used the code in a ESX 5.0 environment that
heavily utilizes dashes in hostnames (some very long) without issue.
Hopefully not a VMware version-specific issue of sorts. Unfortunately, I
don’t have an environment to debug/support the code myself any longer.

On Wed, Apr 9, 2014 at 5:00 PM, Ian Delahorne ian.delahorne@gmail.comwrote:

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.

FWIW I have never had this issue in my environment with knife-vsphere
when cloning templates and VMs. In fact 90% of our VM names contain a
’-’.

//ian

Brian Flad


#5

The spec for DNS hostnames is http://tools.ietf.org/html/rfc1123. I’m surprised at the limitation you see, since I’m generating such hostnames all the time. There are some issues with short names versus FQDN’ which can get confusing.

It does seem clear that knife-vsphere could use some refinement.


Nico Kadel-Garcia
Senior Systems Consultant
Email: nkadelgarcia-consultant@scholastic.com
Cell Phone: +1.339.368.2428


From: Anna Redding amrsun23@yahoo.com
Sent: Monday, April 07, 2014 2:03 PM
To: chef@lists.opscode.com; chef-dev@lists.opscode.com
Subject: [chef-dev] 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


#6

Thank you for the DNS info.

Based on the RFC, my hostnames are compliant so this does appear to be a bug I’m experiencing.

Actually, I believe I have three valid bugs I’ve encountered but want to try and make sure it’s not something weird on the vcenter side of the house before I blame knife-vsphere!!!

Sent from my iPhone

On Apr 7, 2014, at 11:50 PM, “Kadel-Garcia, Nico” NKadelGarcia-consultant@Scholastic.com wrote:

The spec for DNS hostnames is http://tools.ietf.org/html/rfc1123. I’m surprised at the limitation you see, since I’m generating such hostnames all the time. There are some issues with short names versus FQDN’ which can get confusing.

It does seem clear that knife-vsphere could use some refinement.


Nico Kadel-Garcia
Senior Systems Consultant
Email: nkadelgarcia-consultant@scholastic.com
Cell Phone: +1.339.368.2428


From: Anna Redding amrsun23@yahoo.com
Sent: Monday, April 07, 2014 2:03 PM
To: chef@lists.opscode.com; chef-dev@lists.opscode.com
Subject: [chef-dev] 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


#7

Anna,

Naive (or ignorant (or both)) question, perhaps, but…

If as you say ‘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 amrsun23@yahoo.com
Sent: Monday, April 7, 2014 2:03 PM
To: chef@lists.opscode.com; chef-dev@lists.opscode.com
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


#8

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:

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 :slight_smile:

dsp

On 8 Apr 2014, at 05:32, Ross Mohan mohanr@five9group.com wrote:

Anna,

Naive (or ignorant (or both)) question, perhaps, but…

If as you say ‘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 amrsun23@yahoo.com
Sent: Monday, April 7, 2014 2:03 PM
To: chef@lists.opscode.com; chef-dev@lists.opscode.com
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


#9

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 dominique.poulain@kolumbus.fi 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 :slight_smile:

dsp

On 8 Apr 2014, at 05:32, Ross Mohan mohanr@five9group.com wrote:

Anna,

Naive (or ignorant (or both)) question, perhaps, but…

If as you say ‘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 amrsun23@yahoo.com
Sent: Monday, April 7, 2014 2:03 PM
To: chef@lists.opscode.com; chef-dev@lists.opscode.com
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


#10

Anna,

Thanks again for generously sharing your work process.

Completely empathize with wanting to do this all inside Chef. Same here: dispensing with uncorrelated scripts is part of the allure of Chef.

However, while using an Execute Resource to do something like wrap a Here Document or a simple shell out – whether to bash, to powershell, or whatever – is still Chef, it is also a ‘frontier case’.

This is just my (newbie) way of thinking, and more experienced folks may rightfully differ, but this is on the boundary of Chef and the outside world. My excellent instructor in the two day fundamentals Chef class said something along the lines of “…the first thing you should think of if you’re about to code an Execute Resource…is…is there any other way to do this…?”

Ross


From: Anna Redding amrsun23@yahoo.com
Sent: Wednesday, April 9, 2014 1:37 AM
To: Dominique Poulain
Cc: chef@lists.opscode.com; chef-dev@lists.opscode.com
Subject: [chef] Re: [chef-dev] Re: Knife-vsphere vs powetCLI

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 <dominique.poulain@kolumbus.fimailto:dominique.poulain@kolumbus.fi> 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:

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 :slight_smile:

dsp

On 8 Apr 2014, at 05:32, Ross Mohan <mohanr@five9group.commailto:mohanr@five9group.com> wrote:

Anna,

Naive (or ignorant (or both)) question, perhaps, but…

If as you say ‘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 <amrsun23@yahoo.commailto:amrsun23@yahoo.com>
Sent: Monday, April 7, 2014 2:03 PM
To: chef@lists.opscode.commailto:chef@lists.opscode.com; chef-dev@lists.opscode.commailto:chef-dev@lists.opscode.com
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


#11

Ross,

Thank you for your input. I totally agree. And, for the record, I am very much a ‘newbie’ too (as if no one could tell). Lol!!

I am actually using the ‘bash’ resource and here document method to execute some very intensive perl scripts that were written last year by someone else. These do need some modifications to add some checks/balances (not idempotent) and at some point migrated to Chef code, but for my immediate objective, they work perfectly.

So, with that said, the biggest reason I was avoiding the use of powerCLI was because it requires a windows OS to execute. We do not have a windows system in our environments.

The current process is being done using powerCLI but the person who uses it is executing it locally from his VDI.

Since my script is in unix Shell, I must
use a remote execution process. This means I must enable the appropriate windows OS configuration settings on the VDI. And, that leads to the problem that we do not have authorization to do ‘administrator’ level changes on our VDIs. I am going to push somr buttons on that today.

I want to again, thank everyone for your ideas and thoughts. Each one is giving me more clarity on a workaround using powerCLI. I hope two things. 1-we can make the necessary changes on the VDIs and 2-I can sweet talk the program into another extension and give me approval to make/test these changes.

Keep the flow of info coming…it is much appreciated.

Anna

Sent from my iPhone

On Apr 9, 2014, at 12:09 PM, Ross Mohan mohanr@five9group.com wrote:

Anna,

Thanks again for generously sharing your work process.

Completely empathize with wanting to do this all inside Chef. Same here: dispensing with uncorrelated scripts is part of the allure of Chef.

However, while using an Execute Resource to do something like wrap a Here Document or a simple shell out – whether to bash, to powershell, or whatever – is still Chef, it is also a ‘frontier case’.

This is just my (newbie) way of thinking, and more experienced folks may rightfully differ, but this is on the boundary of Chef and the outside world. My excellent instructor in the two day fundamentals Chef class said something along the lines of “…the first thing you should think of if you’re about to code an Execute Resource…is…is there any other way to do this…?”

Ross

From: Anna Redding amrsun23@yahoo.com
Sent: Wednesday, April 9, 2014 1:37 AM
To: Dominique Poulain
Cc: chef@lists.opscode.com; chef-dev@lists.opscode.com
Subject: [chef] Re: [chef-dev] Re: Knife-vsphere vs powetCLI

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 dominique.poulain@kolumbus.fi 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 :slight_smile:

dsp

On 8 Apr 2014, at 05:32, Ross Mohan mohanr@five9group.com wrote:

Anna,
Naive (or ignorant (or both)) question, perhaps, but…
If as you say ‘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 amrsun23@yahoo.com
Sent: Monday, April 7, 2014 2:03 PM
To: chef@lists.opscode.com; chef-dev@lists.opscode.com
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


#12

Anna,

Don’t know any powerCLI yet, but…and apologize if this is woefully misinformed or irrelevant to your needs…isn’t there a massive REST API interface to that?

One of two ways:

Reach through to vCenter functionality through Orchestrator REST APIhttp://pubs.vmware.com/vsphere-55/index.jsp#com.vmware.vsphere.vco_develop_web_services.doc/GUID-E767F363-6FEA-4998-8119-9C51C5A9C73A.html?resultof=%22%72%65%73%74%22%20%22%61%70%69%22%20

or

Rube Goldberg it by using REST API commands to Powershell 3http://technet.microsoft.com/en-us/Library/hh849971.aspx itself (and then from Powershell to whatever you need…)

curl (or wget) could be your new friend…

Regards,

Ross


From: Anna Redding amrsun23@yahoo.com
Sent: Wednesday, April 9, 2014 1:39 PM
To: Ross Mohan
Cc: chef-dev@lists.opscode.com; chef@lists.opscode.com
Subject: Re: [chef] RE: Re: [chef-dev] Re: Knife-vsphere vs powetCLI

Ross,

Thank you for your input. I totally agree. And, for the record, I am very much a ‘newbie’ too (as if no one could tell). Lol!!

I am actually using the ‘bash’ resource and here document method to execute some very intensive perl scripts that were written last year by someone else. These do need some modifications to add some checks/balances (not idempotent) and at some point migrated to Chef code, but for my immediate objective, they work perfectly.

So, with that said, the biggest reason I was avoiding the use of powerCLI was because it requires a windows OS to execute. We do not have a windows system in our environments.

The current process is being done using powerCLI but the person who uses it is executing it locally from his VDI.

Since my script is in unix Shell, I must
use a remote execution process. This means I must enable the appropriate windows OS configuration settings on the VDI. And, that leads to the problem that we do not have authorization to do ‘administrator’ level changes on our VDIs. I am going to push somr buttons on that today.

I want to again, thank everyone for your ideas and thoughts. Each one is giving me more clarity on a workaround using powerCLI. I hope two things. 1-we can make the necessary changes on the VDIs and 2-I can sweet talk the program into another extension and give me approval to make/test these changes.

Keep the flow of info coming…it is much appreciated.

Anna

Sent from my iPhone

On Apr 9, 2014, at 12:09 PM, Ross Mohan <mohanr@five9group.commailto:mohanr@five9group.com> wrote:

Anna,

Thanks again for generously sharing your work process.

Completely empathize with wanting to do this all inside Chef. Same here: dispensing with uncorrelated scripts is part of the allure of Chef.

However, while using an Execute Resource to do something like wrap a Here Document or a simple shell out – whether to bash, to powershell, or whatever – is still Chef, it is also a ‘frontier case’.

This is just my (newbie) way of thinking, and more experienced folks may rightfully differ, but this is on the boundary of Chef and the outside world. My excellent instructor in the two day fundamentals Chef class said something along the lines of “…the first thing you should think of if you’re about to code an Execute Resource…is…is there any other way to do this…?”

Ross


From: Anna Redding <amrsun23@yahoo.commailto:amrsun23@yahoo.com>
Sent: Wednesday, April 9, 2014 1:37 AM
To: Dominique Poulain
Cc: chef@lists.opscode.commailto:chef@lists.opscode.com; chef-dev@lists.opscode.commailto:chef-dev@lists.opscode.com
Subject: [chef] Re: [chef-dev] Re: Knife-vsphere vs powetCLI

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 <dominique.poulain@kolumbus.fimailto:dominique.poulain@kolumbus.fi> 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:

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 :slight_smile:

dsp

On 8 Apr 2014, at 05:32, Ross Mohan <mohanr@five9group.commailto:mohanr@five9group.com> wrote:

Anna,

Naive (or ignorant (or both)) question, perhaps, but…

If as you say ‘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 <amrsun23@yahoo.commailto:amrsun23@yahoo.com>
Sent: Monday, April 7, 2014 2:03 PM
To: chef@lists.opscode.commailto:chef@lists.opscode.com; chef-dev@lists.opscode.commailto:chef-dev@lists.opscode.com
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


#13

Thank you. I will look into those possibilities as well.

Sent from my iPhone

On Apr 9, 2014, at 1:07 PM, Ross Mohan mohanr@five9group.com wrote:

Anna,

Don’t know any powerCLI yet, but…and apologize if this is woefully misinformed or irrelevant to your needs…isn’t there a massive REST API interface to that?

One of two ways:

Reach through to vCenter functionality through Orchestrator REST API
or
Rube Goldberg it by using REST API commands to Powershell 3 itself (and then from Powershell to whatever you need…)

curl (or wget) could be your new friend…

Regards,
Ross

From: Anna Redding amrsun23@yahoo.com
Sent: Wednesday, April 9, 2014 1:39 PM
To: Ross Mohan
Cc: chef-dev@lists.opscode.com; chef@lists.opscode.com
Subject: Re: [chef] RE: Re: [chef-dev] Re: Knife-vsphere vs powetCLI

Ross,

Thank you for your input. I totally agree. And, for the record, I am very much a ‘newbie’ too (as if no one could tell). Lol!!

I am actually using the ‘bash’ resource and here document method to execute some very intensive perl scripts that were written last year by someone else. These do need some modifications to add some checks/balances (not idempotent) and at some point migrated to Chef code, but for my immediate objective, they work perfectly.

So, with that said, the biggest reason I was avoiding the use of powerCLI was because it requires a windows OS to execute. We do not have a windows system in our environments.

The current process is being done using powerCLI but the person who uses it is executing it locally from his VDI.

Since my script is in unix Shell, I must
use a remote execution process. This means I must enable the appropriate windows OS configuration settings on the VDI. And, that leads to the problem that we do not have authorization to do ‘administrator’ level changes on our VDIs. I am going to push somr buttons on that today.

I want to again, thank everyone for your ideas and thoughts. Each one is giving me more clarity on a workaround using powerCLI. I hope two things. 1-we can make the necessary changes on the VDIs and 2-I can sweet talk the program into another extension and give me approval to make/test these changes.

Keep the flow of info coming…it is much appreciated.

Anna

Sent from my iPhone

On Apr 9, 2014, at 12:09 PM, Ross Mohan mohanr@five9group.com wrote:

Anna,

Thanks again for generously sharing your work process.

Completely empathize with wanting to do this all inside Chef. Same here: dispensing with uncorrelated scripts is part of the allure of Chef.

However, while using an Execute Resource to do something like wrap a Here Document or a simple shell out – whether to bash, to powershell, or whatever – is still Chef, it is also a ‘frontier case’.

This is just my (newbie) way of thinking, and more experienced folks may rightfully differ, but this is on the boundary of Chef and the outside world. My excellent instructor in the two day fundamentals Chef class said something along the lines of “…the first thing you should think of if you’re about to code an Execute Resource…is…is there any other way to do this…?”

Ross

From: Anna Redding amrsun23@yahoo.com
Sent: Wednesday, April 9, 2014 1:37 AM
To: Dominique Poulain
Cc: chef@lists.opscode.com; chef-dev@lists.opscode.com
Subject: [chef] Re: [chef-dev] Re: Knife-vsphere vs powetCLI

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 dominique.poulain@kolumbus.fi 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 :slight_smile:

dsp

On 8 Apr 2014, at 05:32, Ross Mohan mohanr@five9group.com wrote:

Anna,
Naive (or ignorant (or both)) question, perhaps, but…
If as you say ‘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 amrsun23@yahoo.com
Sent: Monday, April 7, 2014 2:03 PM
To: chef@lists.opscode.com; chef-dev@lists.opscode.com
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