i hate dealing with them….
I’m currently working on a project to move our server VM infrastructure from our old VMAX3 to a new all flash VMAX 250F SAN. So for my own sanity sake, and to save myself from one less Google search, below is what I used to sVmotion all VMs from the “old” LUN to the new LUN
get-datastore “old-datastore” | get-vm | move-vm -datastore(get-datastore “new-datastore”)
I was tasked earlier in the week to reclaim free space from VMs that have been deleted or from snapshots that have been consolidated.
What I discovered was that from vSphere 5.0 to 5.5 had the ability but was disabled by default due to performance issues on the arrays during reclamation. However, reclamation can still be done manually by issuing the following command
esxcli storage vmfs unmap -l <datastore name>
What is happening here is that when a VM is either deleted, moved due to SvMotion, or snapshots deleted/ consolidated, the VMFS datastore sees that space has been freed up, but not reported back to the array, and still holds on to that space. So in the vCenter client, you’ll see the amount of free space available to you right away, but you’ll the LUN reporting a different number. I think this is normally not an issue as long as your datastores don’t fill up or if you’re running alerts against the datastores and not the array.
In any case the above command reclaims the space, but depending on how big the LUN is, it can take long time.
For example, to reclaim 50% of free space from a 8TB LUN took about 11 hours.
Good news, VMware had re-implemented the SCSI UNMAP commands in 6.5
Please keep in mind the scsi unmap command needs to be run from the host console.
The last few months I’ve had some issues installing certain applications. Some applications would be looking for the msi in the Windows temp directory, in one instance, VAMT would fail with Error 1651.
Well, I’ve finally resolved the issue with the following:
According to the website, the following is fixed:
- Corrupted registry keys on 64-bit operating systems
- Corrupted registry keys that control the update data
- Problems that prevent new programs from being installed
- Problems that prevent existing programs from being completely uninstalled or updated
- Problems that block you from uninstalling a program through Add or Remove Programs (or Programs and Features) in Control Panel
To fix my issues I would select the application that is giving me a problem, select uninstall, and then re-run the installation.
I recently installed MacOS High Sierra (10.13) on ESXi 6.0 for a developer I work with. The steps I used were from a number of sources found on the InterWebs.
First off you need a Mac to download the installer. On the Mac, go to the App Store and and download MacOS. While that is downloading, you’ll need to run the Unlocker script found at insanelymac.com. Please read the notes thoroughly, and yes, a reboot of the host is needed.
After the installer is downloaded, you will need to create the ISO. The following steps are all done on the Mac
Mount the installer:
hdiutil attach /Applications/Install\ macOS\ High\ Sierra.app/Contents/SharedSupport/InstallESD.dmg -noverify -nobrowse -mountpoint /Volumes/install_app
Then create a blank ISO
hdiutil create -o /tmp/HighSierra.cdr -size 7316m SPUD -fs HFS+J
Then mount the blank ISO
hdiutil attach /tmp/HighSierra.cdr.dmg -noverify -nobrowse -mountpoint /Volumes/install_build
Then restore the base image to the blank ISO
asr restore -source /Applications/Install\ macOS\ High\ Sierra.app/Contents/SharedSupport/BaseSysyem.dmg -target /Volumes/install_build -noprompt -noverify -erase
copy the install dependencies
cp /tmp/HighSierra.dmg /Volumes/OS\ X\ Base\ System/
unmount installer image
hdiutil detach /Volumes/OS\ X\ Base\ System
convert to iso
hdiutil convert /tmp/sierra.cdr.dmg -format UDTO -o /tmp/HighSierra.iso
rename to iso and place on Desktop
mv /tmp/HighSierra/iso.cdr ~/Desktop/HighSierra.iso
Enjoy on non Apple Hardware!
I was recently asked to get a list of all VMs in a certain VLAN along with OS and IP address. To do that…
get-vdportgroup “<name of port group>” | get-vm | get-guest | select vm, ipaddress, osfullname | ft -autosize
if you happen to be on a standard switch, replace get-vdportgroup with get-virtualportgroup -name <name of portgroup>
I recently updated my Nexus 9 to the nightly build of LineageOS 14.1 October 10. The normal update went smoothly. However, after rebooting, I was greeted with “A vendor mismatch has been detected. Typiucally this means yopur vendor image is out of date. Please ensure that your vendor image matches N9F27M”
According to Lineage, the nightlies are based on the October monthly updates from Google. Which means the vendor image needs to be extracted from the factory image from Google and updated on the Nexus 9.
Once the vendor img has been extracted or downloaded, you’ll need to use adb fastboot to install it.
- Connect to N9
- adb reboot bootloader
- fastboot devices
- fastboot vendor vendor-flounder-n9f27m.img
- fastboot reboot
N9 will reboot and you should no longer get that popup box
I’ve recently created an AppStack that included FireFox 52.4.1 ESR with the flash plugins and the VMware Client Integration Plugin. I first created 3 separate AppStacks, FireFox, FlashPlugins and FireFox with the VMWare Client Integration Plugin. Running all these plugins seem to run fine. It’s when I created an all in one AppStack I encountered issues with the CIP.
After the AppStack was deployed, I ran FireFox and kept getting the following
Quite annoying, so after much searching I find out that the certificates generated during the provisioning process do not get captured by AppVolumes when you complete provisioning. The ssl folder on the target system shows as single file:
It should look like this:
For this to work right, CIP needs to have the certs in this location. So to achieve this, I updated the FF AppStack, copied the CIP folder to C:\ProgramData, modified the allappvolattached.bat to include:
Powershell Copy-Item c:\programdata\cip\ c:\programdata\vmware\ -Recurse
After re-provisioning the AppStack, I was step closer. The pop-up was gone, but the CIP piece was still not working.
After much searching again, I made the following changes:
Turned off the proxy, using direct internet connection
toggled the following to false
and made the following changes to the host file
After a reboot, the CIP started working.
Another long day of troubleshooting an AppStack.
Good news is, I’m fairly confident in creating AppStacks and troubleshooting it now.
Check out the pricing models for VMC-AWS. This looks promising, however, I’m a little weary about the data transfer charges.
About 2 weeks ago, I noticed in vRealize Operations Manager that one of my VDI hosts was experiencing higher than normal CPU contention. What was more interesting was that 90% of all VMs on that host had high cpu usage. Moving a VM off the host, brought down CPU utilization, however, any VM moving to that host, started experiencing the same behavior. After a few searches it turned out that the host’s power setting was set to balanced. After setting the to Static High Performance Mode, the CPU contention dropped to below threshold and CPU demand on the host dropped as well.
So note to self and to others, when setting up hosts, set the power to high performance. Luckily for me a reboot was not required. This may be differ among vendors though.
Week of 9/24
Past 7 Days
You can see above where I made the change.