Thank you. I will look into those possibilities as well.
Sent from my iPhone On Apr 9, 2014, at 1:07 PM, Ross Mohan <
">
> 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 <
">
>
Sent: Wednesday, April 9, 2014 1:39 PM
To: Ross Mohan
Cc:
">
;
">
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 <
">
> 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 <
">
>
Sent: Wednesday, April 9, 2014 1:37 AM
To: Dominique Poulain
Cc:
">
;
">
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 <
">
> 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
|