New Datacore Witness against Split-Brain scenario

DataCore SANsymphony offers software defined storage with transparent mirror in active/active mode.

Recently released version 10 PSP7 now supports a witness to avoid split-brain scenarios.

The Problem

In cases where both DataCore hosts (DC1, DC2) lose mirror (MIR) paths and LAN-connection, a split brain scenario occurs.

Both hosts remain functional and have a fully intact set of data on their storage. Both hosts can handle I/O from initiators in their (split) region. Both datastores receive writes that cannot be mirrored to the opposite site. Those changes cannot be synced if the mirror comes up again. Continue reading “New Datacore Witness against Split-Brain scenario”

Veeam ReFS Repository on iSCSI Targets

Troubleshooting Repository Deadlocks

With Resilient Filesystem (ReFS) integration into Veeam Availability Suite 9.5 a whole bunch of features was integrated. One of the biggest advantages is ‘Fast Cloning Technology’ which enables synthetic full backups by merely creating pointers to already existing datablocks on the repository.

In a small scale environment I had a hardware repository server (Win 2016) with an iSCSI Volume as repository (ReFS, 64k) as primary backup target. This constellation worked like a Swiss watch. Daily backups ran for months without any trouble. Fast cloning technology enabled weekly synthetic full backups with minimal consumption of extra space.

Recently I’ve added another iSCSI Volume (ReFS, 64k) to be used as repository for backup copies. That’s when the fun began… Continue reading “Veeam ReFS Repository on iSCSI Targets”

Change Brocade FOS default passwords

Brocade FC-Switches are equipped with four default useraccounts: admin, root, user and factory.

By connectiong an SSH session with user ‘root’ and default password ‘fibranne’ you will be prompted to change logins for accounts root, user and factory.

 

This happens at login as long as you did not change default passwords. The process can be started by pressing <ENTER>. If it is skipped by pressing Ctrl-C you will be prompted again at next login of user ‘root’

Show users

userconfig --show -a

This command will show a list aof all local users and their settings.

 

vMotion fails at 21% with error 195887371

How to troubleshoot vMotion issues

Troubleshooting vMotion issues is in most cases a matter of networking issues. I will demonstrate in this case how to trace down the problem and how to find possible culprits.

What’s the problem?

Initiating a host vMotion between esx1 and esx2 passes all pre-checks, but then fails at 21% progress.

Migrate virtual machine:Failed waiting for data. Error 195887371. The ESX hosts failed to connect over the VMotion network.

See the error stack for details on the cause of this problem.
Time: 07.01.2018 19:08:08
Target: WSUS
vCenter Server: vc
Error Stack
Migration [167797862:1515348488969364] failed to connect to remote host <192.168.45.246> from host <10.0.100.102>: Timeout.
vMotion migration [167797862:1515348488969364] vMotion migration [167797862:1515348488969364] stream thread failed to connect to the remote host <192.168.45.246>: The ESX hosts failed to connect over the VMotion network
The vMotion migrations failed because the ESX hosts were not able to connect over the vMotion network. Check the vMotion network settings and physical network configuration. 
Migration [167797862:1515348488969364] failed to connect to remote host <10.0.100.102> from host <192.168.45.246>: Timeout.
vMotion migration [167797862:1515348488969364] failed to create a connection with remote host <10.0.100.102>: The ESX hosts failed to connect over the VMotion network
Failed waiting for data. Error 195887371. The ESX hosts failed to connect over the VMotion network.

Continue reading “vMotion fails at 21% with error 195887371”