Month: January 2018

1. Log into the vSphere Client and select the host from the inventory panel.
2. Click the Configuration tab and select Networking.
3. Click Add Networking and choose VMkernel as the Connection Type.
4. Click Next.
5. Add two or more NICs to the required standard switch. You can create a new vSphere standard switch or use an existing vSwitch.Note: Ensure that all adapters are on the same network when connected to a physical Ethernet environment. If the adapters are split across switches, then all adapters must be able to communicate across those switches.
6. Name the VMkernel portgroup (for example, vMotion-01), and assign a VLAN ID as required.
7. Click Use this port group for vMotion, then click Next 
8. Configure the IP address and subnet mask, then click Next..
9. Click the Properties tab of the vSwitch, select the vMotion-01 portgroup, and click Edit.
10. Click the NIC Teaming tab.
11. Under Failover Order, select Override switch failover order.
12. Configure the first adapter (for example, vmnic1) as active and move the second adapter (for example, vmnic3) to Unused Adapters.
13. Click OK.
14. Under the vSwitch Properties, click Add to create a second VMkernel portgroup.
15. Name the VMkernel portgroup (for example, vMotion-02), and assign a VLAN ID as required.Note: Ensure that both VMkernel interfaces participating in the vMotion have the IP address from the same IP subnet.
16. Click Use this port group for vMotion, then click Next.
17. Configure the IP address and subnet mask, then click Next.
18. Click the Properties tab of the vSwitch, select the vMotion-02 portgroup, and click Edit.
19. Click the NIC Teaming tab.
20. Under Failover Order, select Override switch failover order.
21. Configure the second adapter (for example, vmnic3) as active and move the first adapter (for example, vmnic1) to Unused Adapters.
22. On the Properties tab of the vSwitch, select each vMotion portgroup in turn and confirm that the active and standby adapters are the reverse of each other.
23. I repeated the tasks above two more times because I have four nics for iSCSI traffic. Each nic went to its own physical network card, which was further bound to the Software iSCSI HBA.

In the below picture, you can see an inbound migration at the beginning of the graph, and later after the configuration you can see the same machines migrated outbound post configuration on both vHosts.

I’ve updated our system to 7.0.0.37394 of vRanger Backup and Replication and found a really confounding bug – or problem with it.
We were rolling along just fine with 6.1.0.35402 backups worked, Everyone was happy. Then disaster happened: we lost a drive in the SAN and the database that held our logs was gone. I’m the kind of guy that likes to make things better, so with a chance to upgrade our software, since our backup logs were lost, I thought what better time to do so than now. YAY. Well when you go to make a new repository in vRanger, you’ve got to pay attention to the CaPiTaLiZaTiOn of your path, such that \\backupdevice\dir\backupfolder is not by chance \\backupdevice\dir\BackupFolder as was my case using either NFS or CIFS. Backups were failing with the message: “Backup failed: Error: 2258 – FATAL cifs_cant_mkdir CIFS can’t create the directory cifs:localhost;admin@backupdevice/public/backup/* (No such file or directory) [at cifs_mkdir:615″ where I should have had “backupdevice/public/Backup”
Oh the maddness ensues because when I went back through the installation, vRanger validates the path as correct!!! This happens on the vRanger Virtual Appliance (vRanger-VA). SO, if you get that message on a fresh install, check your path statement. – OR just use all lower case letters.

That claim is simply not true. If the consumer asks for the statement in writing, he will not receive it. Nevertheless, the consumer may feel uneasy about using replacement filters that are not original equipment. With the large number of do-it-yourselfers who prefer to install their own filters, this misleading claim should be corrected.

Under the Magnuson – Moss Warranty Act, 15U.S.C. SS 2301-2312 (1982) and general principles of the Federal Trade Commission Act, a manufacturer may not require the use of any brand of filter (or any other article) unless the manufacturer provides the item free of charge under the terms of the warranty.

So, if the consumer is told that only the original equipment filter will not void the warranty, he should request that the OE filter be supplied free of charge. If he is charged for the filter, the manufacturer will be violating the Magnuson – Moss Warranty Act and other applicable law.

By providing this information to consumers, the Filter Manufacturers Council can help to combat the erroneous claim that a brand of replacement filter other than the original equipment will “void the warranty.”

It should be noted that the Magnuson – Moss Warranty Act is a federal law that applies to consumer products. The Federal Trade Commission has authority to enforce the Magnuson – Moss Warranty Act, including obtaining injunctions and orders containing affirmative relief. In addition, a consumer can bring suit under the Magnuson – Moss Warranty Act.

1. Open a console prompt on the ESX host or initiate an SSH connection to it.
2. Type esxtop and press Enter.
3. In the CPU screen, check the %CSTP value. If this number is higher than 3.00, the performance issues may be caused by the vCPU count. Try lowering the vCPU count of the virtual machine by 1.Note: The %CSTP value represents the amount of time a virtual machine with multiple virtual CPUs is waiting to be scheduled on multiple cores on the physical host. The higher the value, the longer it waits and the worse its performance.  Lowering the number of vCPUs reduces the scheduling wait time.
4. In vCenter, you can also edit the realtime graphs to show Co-Stop:

As a general rule, I recommend starting with one processor and upgrading to multi-processors if it is really necessary. Case in point: I have a DBA that wanted 8 processors for his Oracle Database, I initially gave it to him, but soon the DB began this power grab on the vHost. Once I convinced him it was his server causing the issues, we rolled the system back several processors and the DB worked much better.

To heck with metallic pads.
Go with ceramic pads for your disk brake needs. They don’t make as much brake dust and they last so much longer.
Another thing to consider is that instead of turning your rotors, just replace them every other time you change the pads. It just doesn’t pay to turn them anymore.
Also. Changing your pads and rotors is super easy and can be done with simple tools, the only “special” tool I used was a large C clamp. It took about 45 minutes to do both sides and I got a good health check of the car while I was under there.