Search This Blog

Brocade FC Switch FOS v7.2.0a WebTools Access in Windows Server 2012 R2 with IE 11

I got some errors (see at the end of the post) when setting up a brand new Brocade Fibre Channel switch running FOS v7.2.0a on a Windows Server 2012 R2 server with IE 11. The following instruction fixed the error.

  • Install Oracle JRE 1.7.0 update 25 Windows x86 version
    • According to its release note, FOS v7.2 is qualified and supported only with Oracle JRE 1.7.0 update 25.
    • Install JRE Windows x86 version (32-bit), instead of Windows x64 version (64-bit) even Windows Server 2012 R2 is a 64-bit OS
  • Launch “Java (32-bit)” in Control Panel
    • Security tab, lower Security Level to Medium
    • java.security
    • (optional) Advanced tab, set “Perform certificate revocation checks on” to “Do not check”. This will speed up the “Verifying application” process if the server does not have the Internet access.
    • java.advanced
  • Launch Internet Explorer
    • Click Tools, “Compatibility View settings” to add the Brocade switch IP address to the compatibility view list
    • ie.compatibility.setting.01
    • ie.compatibility.setting.02
  • Enter the IP address of the Brocade switch in Internet Explorer
    • brocade.fc.webtool.01
    • brocade.fc.webtool.02
    • brocade.fc.webtool.03

The error messages I experienced and possible solutions

  • “The version of Java plugin needed to run the application is not installed. The page from where the plugin can be downloaded will be opened in a new window.”
    • Install the supported JRE version. see FOS release note for the supported JRE version
    • Install the 32-bit version of JRE, instead of 64-bit version
    • Verify Java Plug-In is enabled in IE
    • Add the FC switch IP to IE’s compatibility list
  • “Unable to launch the application” or “Unable to load resource: http://<switch-ip>/loc_res.jar
    • Install the supported JRE version. See FOS release note for the supported JRE version
  • “Application Blocked by Security Settings”
    • Lower the Java Security to Medium in Java 1.7 Update 25. For the newer version of Java, add the FC switch URL to the Java Security Exception Site List.

Create CD/DVD ISO File in Windows 10

Windows 8 or later has the built-in feature to open / mount ISO files. However, creating an ISO file requires other tools. There are many free utilities available.

Today, I tried ISO Recorder v.3.1.3 64-bit. The last update on its web support says it supports Windows Vista and 7. In my test, it works in Windows 10 as well.

Create an ISO file

There is no icon or shortcut to launch ISO Recorder after the installation. To create an ISO file, right-click on the CD / DVD drive, and select “Create image from  CD/DVD”.

iso.recorder.create

Mount an ISO file

Before installing ISO Recorder, Windows 10 will automatically mount the ISO to a virtual CD when double-clicking an ISO file. After installing ISO Recorder, double clicking an ISO file will launch ISO Recorder to write the image to a CD.

To mount the ISO file, right-click on the ISO file, and select “Open with” and “Windows Explorer”.

iso.recorder.mount

PS. I almost forget another free tool - ImgBurn. This was my go-to CD ISO creation and writing tool. The current version is v.2.5.8.0 released on June 16, 2013. This may still work in Windows 10, but I have not tried it yet.

Other free CD tools: MagicISO Virutal CD, WinISO 5.3, and CDBurnerXP.

Do Not Upgrade Dell Server with H730 and FD332-PERC Controller to VSAN 6.2

VMware released VSAN 6.2 on March 15, 2016. However, if your VSAN is running on a Dell server with H730 or FD332-PERC controller, do not upgrade to VSAN 6.2.

See KB2144614 for more information.

My IOPS Calculator

I look for an IOPS calculator for the EMC VNX2 5400 storage that I am working on. There are many available on the Internet. But none of them gives me exactly what I want. More frustrated, different calculators produce different results. So I decide to build one myself. Here is what I get.

My IOPS calculator concept:

 

My IOPS Calculator Download (save the spreadsheet and open in Excel)

Fix “Deprecated VMFS volume(s) found on the host” in vSphere 6.x

An ESXi 6.x host shows an warning message “Deprecated VMFS volume(s) found on the host. Please consider upgrading volume(s) to the latest version.”

vsphere.6.deprecated.vmfs.warning

After verifying all the datastores mounted on the host are VMFS5, I restarted the management agent on the host. That cleared the warning.

This is a known issue on vSphere 6 (KB2109735).

VSAN Free Storage Catches

VSAN is a hot topic nowadays. Once it is set up, it’s easy to management and use. No more creating LUN and zoning.

We recently experienced some catches about its free available storage - at least we didn’t think about or were told before; or maybe our expectation to VSAN was too positive.

Our VSAN hardware disk configuration:

  • 3 x Dell PowerEdge R730 nodes
  • 2 x 400 GB SDD per node (372.61 GB is shown in VSAN Disk Management)
  • 14 x 1 TB SATA per node (931.51 GB is shown in VSAN Disk Management)
  • Two disk groups (7 SATA + 1 SSD) per node

Calculation of each node storage capacity (RAW):

931.51 x 14 = 13,041.14 GB = 12.73549 TB

Total storage capacity (RAW)

931.51 x 14 x 3 = 39,123.42 GB = 38.20646 TB

This calculation matches the storage capacity shown in the VSAN Cluster’s Summary.

vsan.total.storage.capacity

We are adding more VMs to the VSAN. Once the free storage drops below about 12 TB (about one node’s RAW capacity), the VSAN health check starts showing critical alert “Limits Health - After 1 additional host failure” (KB2108743).

vsan.health.alert

And the component resyncing starts more frequently.

vsan.resyncing.components

My take away:

  • I understand there is an overhead for VSAN (or any storage product) to offer the redundancy. But the way VSAN displaying the free storage is quite difference than the traditional SAN storage and it can be confused. The free storage shown in VSAN does not mean you should use it. Otherwise, the VMs may be down when a host is down or taken down for maintenance.
  • The used storage in the Summary tab is the previsioned storage, not the actual space in use.
  • The frequent resyncing component can potentially impact the overall VSAN storage performance.

Recover Microsoft Cluster VMs Not Power On After Migration

A lesson to remember if you do not have the time to read this entire post: do not migrate the cluster VMs without fully understanding the impact.

Here is our story.

We had a Microsoft SQL 2008 Cluster VMs in the CIB (see my previous post about various Microsoft Cluster VMs configuration). The shared disks of the cluster VMs were on an EMC SAN. When the free space of EMC SAN was running low, an engineer migrated the cluster VMs (the VMs were powered off during the migration) to the VSAN v.6.1 hosts and storage. The migration completed successfully, but the VMs would not power on with the error message “Cannot use non-thick disks with clustering enabled (sharedBus='physical'). The disk for scsi1:0 is of the type thin.”

Because VSAN does not support Microsoft Cluster with the shared disk (non shared disk cluster, e.g. SQL AlwaysOn Availability Group is supported), this is no option but migrating the VMs back to the original hosts and SAN storage.

PS: In this case, the new target storage is VSAN. I think if the new target storage were the traditional SAN,  the cluster would break too. Because the cluster VMs were not shared anymore after the migration (see below). But you probably could recover the cluster by reconfiguring the VMs to share the shared disks without migrating the VMs back to the original storage.

When we reviewed the disks of the migrated VMs on the VSAN storage, each VM had its own copy of the shared disks. So the cluster VMs were not shared the shared disks any more. We could not simply migrate the VMs back to the original hosts and SAN storage.

When we reviewed the original EMC SAN storage, the VMDK files of the shared disks were still left there, only the non shared disk (e.g. the OS’s C drive) was completely migrated to the VSAN storage.

vmdk.files.left.on.the.san

Recovery Procedure:

  1. Document the SCSI controller ID (e.g. SCSI (1:0)) of each shared disk from the migrated VMs. This may not be very important. But we are going to use the same SCSI controller for each corresponding disk when re-adding the shared disks
  2. Since the VMDK files of the shared disks were still left on the original SAN storage, we can speed up the recovery by migrating the non shared disks of each VMs only. In this case, we are only migrating the hard disk 1 of each VM (the OS drive) back to the original SAN.
  3. How to migrate only the OS drive back to the original host and storage? We used VMware vCenter Converter, and only select the hard disk 1. This worked beautifully.
    • vmware.converter.select.os.drive.only
  4. PS. In this case the VMs were migrated to the VSAN storage. We could not use scp to copy the VMDK file manually between the hosts. If we want to use scp, we need to migrate the VMDK files to a non-VSAN storage first. This is why I think vCenter Converter is the best tool in this case.
  5. Now the non-shared disk of each VM are back to the original host and SAN storage. Make sure both VMs are registered on the same ESXi host.
  6. If the VMs were not on the same ESXi host, use Migrate, Change host, check the checkbox “Allow host selection with this cluster” (this option is not selected by default) to put both VMs on the same ESXi host.
    • vm.migrate.allow.host.selection
  7. Re-add the SCSI controller(s) to the first VM and set the SCSI Bus Sharing to Virtual
  8. Re-add the shared disks using the existing VMDK files to the first VM; match the SCSI ID documented in the first step. We also make sure the order of the hard drives matching the original VM’s configuration
    • re-add.hard.drive.with.existing.vmdk 
  9. Power on the first VM
  10. Log in Windows and verify the shared drives’ drive assignments are correct
  11. Launch Failover Cluster Manager to verify the cluster services and applications are online
  12. Re-add the SCSI controller(s) to the second VM and set the SCSI Bus Sharing to Virtual
  13. Re-add the shared disks using the existing VMDK files to the second VM; match the SCSI ID documented in the first step
  14. Power on the second VM
  15. Log in Windows and verify no shared drive is shown in Windows Explorer, and they should be shown “reserved” in the Disk Management
  16. Launch Failover Cluster Manager to verify the second node is online

Use WinSCP to Transfer Files in vCSA 6.7

This is a quick update on my previous post “ Use WinSCP to Transfer Files in vCSA 6.5 ”. When I try the same SFTP server setting in vCSA 6.7...