I encountered a Health Message for my VCSA 188.8.131.52200 Build Number 5326079.
This led me to Increasing the disk space for the VMware vCenter Server Appliance in vSphere 6.0 (2126276) | VMware KB
However, in the process, I noticed a more serious issue with /storage/log (/dev/mapper/log_vg-log). It was at 98% capacity.
According to the KB article and other reliable sources, I needed to increase VMDK5 to resolve the immediate issue with /storage/log. So, I right clicked the vCenter VM, selected “Edit Settings,” clicked “Manage other disks” (on the Virtual Hardware tab), and increased Hard disk 5 from 10GB to 15GB.
Here is the original configuration:
…and here is how it looked after modification (the sizes were grayed out at the time because vCenter was being backed up by a program that utilizes snapshots and you cannot alter disk size when snapshots are present). Anyway, you will see that Hard disk 5 went from 10 to 15 GB.:
Here is the SSH/Shell before and after:
The Wrong Trousers
Notice something unexpected? Apparently, for my implementation, Disk 5 correlates to /storage/db and NOT /storage/log. In fact, based on this result, it appears that Disk 6 is the one that needs to be grown. Again, that does NOT correlate to other documentation as Disk 6 is referenced as /storage/db in those places.
On a whim and a prayer, I repeated the process for Disk 6, hoping to grow the /storage/log VMDK. Disk 6 was initially 10GB. I changed it to 20GB. Annnnd, bingo:
I’ve encountered this problem in a myriad of ESXi host versions and vCenter versions. For unknown reasons, I am able to migrate some VMs and not others. I’ve tried a number of resolutions in various KB articles, but the only approach that has worked thus far is removing the VM from inventory and adding it back.
Symptoms: Migrate, Move To, Remove from Inventory, and Delete from Disk options are greyed out for a powered-on VM.
To resolve this issue, remove the virtual machine from the vCenter Server Inventory and add it back. Note: When removing a virtual machine from the vCenter Server Inventory, the previous performance statistics for the virtual machine are lost.
Caution: Before performing these steps, make a note of the datastore where the virtual machine resides.
- In the vSphere Client, right-click the powered-off virtual machine and click Remove from Inventory.
- Click Yes when prompted to confirm the removal.
- Click Home > Storage
- Open the Datastore and folder where the VM’s vmx file is stored
- Right-click the .vmx file and click Register VM. This might be “Add to Inventory” in earlier versions.
- Follow the steps in the wizard to add the virtual machine back to the Inventory.
- Click Home > Hosts and Clusters.
- Right-click the virtual machine. The migrate option is now available.
I recently encountered an issue where an ESXi host upgrade caused it to lose it’s connection to an iSCSI datastore. I was finally able to get the iSCSI issue resolved, but then I had an issue where I needed to name the newly created connection the same as the previous. The “old” one was still listed as an “inactive” datastore. I couldn’t name it the same as the old one, but there was no option to delete the old datastore reference.
I finally figured out that I had to remove all VMs from inventory that were still dependent on the “old” datastore. As soon as I deleted those VMs from inventory, the “inactive” datastore was automatically removed. Then I could rename my new iSCSI datastore to match the one that the system marked inactive when the original issue happened during the upgrade.
To avoid “Unable to open log file” and “log.nsf: File does not exist” errors remember to always start Powershell in “Run as Administrator” mode.
In newer versions like Microsoft Windows Server 2012 R2, navigate to the Domino binary directory and then prepend “.\” (without the quotes and with now spaces) before the traditional nwhatever.exe
For example, when binaries are at c:\lotus\domino and you want to run a copy-style compact on the entire data directory…
Start Powershell in “Run as Administrator” mode and your command line will look like this:
PS C:\lotus\domino> .\ncompact.exe -c
This procedure is entirely based on the information obtained from this You-Tube video. I simply needed to refer to the procedure multiple times when experimenting with DD-WRT, OpenWRT, and the stock firmware and it is more efficient for me to follow the written form. The procedure works perfectly for my TL-WR841N V11.x. Please follow Richard Lloyd’s YouTube page for this and other useful information in video format. I didn’t do it; nobody saw me do it; there’s no way you can prove anything!
- Download the version-specific firmware for your TL-WR841N from TP-LINK’s website. My TL-WR841N V11 works well with Firmware Version: 3.16.9 Build 150616 Rel.52099n.
- Unzip the downloaded firmware.
- Rename the extracted file to wr841nv11_tp_recovery.bin (v11 is used because the hardware (and firmware) is for a Version 11 router).
- Download and install the 32-Bit version of Tftpd32 found here.
- Disable your wireless card(s).
- Connect your PC directly to the router’s port #1 using a network cable.
- Assign the following static IP information to your PC’s NIC:
- IP address: 192.168.0.66
- Subnet mask: 255.255.255.0
- Leave all other network settings “as is.”
- Launch Tftpd32 and set:
- Server interfaces: 192.168.0.66 (via the drop-down selection)
- Current Directory: The directory where your renamed firmware from step 3 resides. You can click the “Show Dir” button to confirm that the firmware is visible in the chosen directory.
- Hold and continue holding the “WPS/RESET” button for three seconds after using the ON/OFF button to power-cycle the router.
- You should see the router grab the firmware update from the TPTP Server status window. The router’s peer address during this process is 192.168.0.86:xxxx.
- Close Tftpd32 and wait a minute or two for the router to “settle.”
- Change your PC’s NIC from static back to “Obtain an IP address automatically.”
- Open 192.168.0.1 in a browser and confirm that the TP-LINK firmware loaded correctly.
This applies to a Samsung Micro SDXC xGB EVO Memory Card that I recently purchased (and probably a wider range of similar Samsung cards). Despite a long search, I couldn’t find any information (even on Samsung.com) about which of the tiny sets of numbers and letters on the back of the card constituted the serial number.
I’ve finally figured it all out. On the back of the card, there are 4 lines of information. From top to bottom as it relates to the sample image:
Line 1 is the Model Number > MB-MP32D (the 32 signifies 32 GB, in this case)
Line 2 is the Lot ID > MBMPBGVEQBFW-B
Line 3 is the Serial Number > DHTA410GG407
Line 4 is the Country of Manufacture > MADE IN KOREA
EDIT: Based on a comment posted by KK, MAY 18, 2017 AT 1:10 PM, I’ve reviewed the product packaging. KK was advised by Samsung Canada Customer Support that the serial number is not on the memory card and is, instead, on the product packaging. I happen to still have the replacement card that Samsung provided under warranty in the original packaging. Unfortunately for this agent at Samsung Canada support, there is no evidence of a serial number anywhere on the outside of the packaging. Upon opening the blister pack, I found no numbers on the inside of the packaging, either.
The first task is to verify if you have a WNDR3400 V1, 2, or 3. I used this site to determine I have a V1 device. As the hardware for each version is significantly different, this procedure ONLY applies to V1.
According to what I found here (Sat Jun 11, 2016 4:06 post by mrjcd), the latest known good version of dd-wrt for this router is v24-27858_NEWD-2_K2.6. When going from stock firmware (as I am), use dd-wrt.v24-27858_NEWD-2_K2.6_mini-WNDR3400.chk.
- Reset the router
- Connect via Ethernet cable to the router’s #1 port
- Access the firmware update page at http://192.168.1.1 using the default admin/password login
- Upload the dd-wrt firmware
- Wait for the firmware to upload and for the router to restart
- Access the default dd-wrt Router Management page at http://192.168.1.1
Additional Reference: The infamous “Peacock Thread”