golddiggie's Posts

I was talking with someone else a this afternoon and he seems to think the DNS values entered in the setup is the source of the issue. I've attempted to remove the extra items from the vami page, but I cannot (won't let me confirm the account at the third step). I've also attempted to edit the resolv.conf file. When I clear that, then restart the service, it reverts to the old setting. Any idea as to HOW to get the changes to stick? There has to be a way to get this changed to either fix it or rule the entries as the issue source.  I've rebooted the vCSA at least a handful of times at this point (since the issue presented) without that doing any good. I've done it today as well, after editing the resolv.conf file the first time. I've restarted the service the last couple of edit attempts too. No joy.

Thanks... I used some of the information from a previous script you provided to add the vCenter name to the output file. Since we could be running this against over a dozen vCenters, keeping it clear as to which it's run against is not a minor thing.

Actually, just wanted it saved as a csv so we can do whatever we want with it. Since I'm sure we'll probably save the files for use later. Or as a check done after a environment build in a 'true-up' effort. Mostly because we're seeing cases where our production and recovery sides are not in sync.

Thanks LucD... As always, quick to come up with a working solution to what's requested. Now we have a way to get the list... One quick question... Is there an easy way to have the report.csv file name have the vCenter name in it (at the start)?? That way if it's decided to run this through automation, we can have the report named correctly and not have them write over each other.

Just a quick update on getting 6.7 installed on a host using 'unsupported' processors. I added a new host to my home lab recently. Once I had that up to the current 6.7 release (also updated vCenter before doing that) I was able to also update the old host to 6.7 (using the GA iso). This surprised me a bit since I wasn't able to do an install with the offline package previously. Either way, it did work in this instance. No way to know if this will work for everyone, or anyone else. But it's worth a try if you're looking to get onto 6.7 with older hardware. It also beats trying to do a clean install off of CD/ISO (if you have remote console access). BTW, my new host is a small Supermicro box with IPMI (similar to iDRAC/iLO). I plan to get a second one within the next ~6 months so that I can use HA/DRS. Also, I'm using licensing off of the VMUG Advantage membership. Well worth the $180-$200 a year IMO.

We're looking to gather this same information for a set of VMs we get in a report (daily) that changes. I'm hoping that our 'scripting guy' can add your code to the existing script, targeting only the VMs it's reporting on and add the information in additional columns. If he cannot get it to work, I'll be creating a thread of my own asking for some assistance. I suspect LucD would come up with what needs to be tweaked in <10 minutes of the thread being created.

I have been using the datastore cluster name in that field. In the first script (not yours) that I used, it would only go to one DS, even when I used the cluster name. I can't post the error right now since we're in the process of testing out a few methods to get these updates applied. The problem, IIRC, was that tools crashed when we went to execute the update on those VMs. Some would come back after a reset, but not all. We ran a different command set against a smaller set of VMs (spread out over several vCenters/host clusters) this morning and out of 32 targets, we had one that we had to uninstall and reinstall the tools to get that one resolved. Tools were running, and not reporting any issues, before we kicked off the update task. It was driven through VUM. Now, we're looking to see about flipping the switch for 'update on boot/reboot' for the tools and HW version. That way, since OS patches also are going to be applied, the VM will reboot and apply the tools update during those reboots. Same thing for the HW version update. I did export the events from the past 36 hours and it didn't show any errors. Even though we saw them in the tasks. Looking in the tasks listing, I can see errors, but they're generic. The target VMs have been deleted since the tasks were done (to get into a clean state with the VMs). Of course, ONE of the vCenters is still on 5.5 and the thick client was being a total ballbag to us today. Lagging like a you would not believe. The web client was fine, except it doesn't have VUM available. But, we were able to get the tools updated (struggled to get the 5 VMs that were in that set to remediate) and then we ran the script again to also get the HW version updated. That configuration is slated to be decommissioned sometime in the coming months, so no version updates are going to happen there. I have 53 VMs to update on my window tomorrow at 10am (EST). That includes the 5.5 vCenter/environment. Plus another 6 vCenter Servers/environments.

The lab vcenter, and setup, isn't being hit with anything else since it is out sandbox lab to use/abuse. Three hosts with 7 datastores (in a cluster, 2TB per DS). No other processes are running, or people using this setup while I am. If there are specific logs you want pulled, let me know and I'll see what I can do. I was just hoping to get this more time efficient, but also have it balance across the datastores in the cluster. When I kicked it off yesterday, it would do each clone task in turn and not progress to the next until that was finished. Not the behavior I saw in the other script. The issue with the other script was it would blast all the clones to a single datastore and make it go to a yellow alert state. With SDRS enabled (storage cluster), it's a pain in the ballsack to try and manually balance it after the fact. I would have hoped that it would do it on generation (accept recommendations automagically).

OK... Is there an easy way to get the cloning script to do more than one execution at a time?? Also, when I ran it to do 100 it bombed. I split it into four 25 clone task chunks and they didn't bomb on me. If I could even have 5-10 clone tasks running at the same time to get the 100 count, that should be enough to make it go fast enough. I've removed the line to make the VMs thin provisioned since the source already is. So it can clone at the original provisioning type. At least the VMs didn't all get dumped into a single datastore this time. We also did a test run of the VMware Tools and HW version update script against the 100 clones. We had a 10% failure rate on the targets. It also took about 30 minutes to get them completed. We're looking into how we're going to do this at scale, inside the time frame we have. We need to get up to about 350 VMs processed in less than a two hour window (at a time). Some of the vCenter's will have upwards of 130 being processed at a single time (we have 15 vCenter Servers in total). I'm wondering if having the NIC disconnected (on boot too) on the test targets is part of the issue. We don't need them to have any network access, since they're only to test the update tasks/scripts. Side question since I can't recall exactly... Do you need to update the tools or hardware version first? Does it matter with 6.5u1? I seem to recall reading to do the HW version first, then tools. Right now, I think the tools are getting updated first, then the HW version.