Author: harlan

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.