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’
userconfig --show -a
This command will show a list aof all local users and their settings.
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
vCenter Server: vc
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”
Agile backup job assignment with VM-tags and Veeam Backup
Organizing VMs in backup jobs can be a tedious task. Especially when there is a larger number of VMs and multiple jobs. It might happen that you miss out a VM for a job, or have it doubled.
To check whether a VM is backed up by the corresponding jobs, you either have to go through the settings of every single job or use smart tools like Veeam-One.
There are a couple of ways to add VMs to a backup job. You can choose single VMs by name, or select an entire VM folder, resource-pool or datastore. But one of the most sophisticated and versatile methods is to leverage VM-tags for selection.
What are tags?
A tag behaves like a label or a sticker that you put on a VM. It defines a property or a membership of a given VM. Think of a tag that marks a VM for daily backup. A second tag might mark a VM for hourly or weekly backup. You don’t have to adjust your backup jobs twice a week to remove or add new virtual machines. With VM-tags you don’t have to touch backup jobs at all. Just tell the job once to select all VMs with a specific tag and you’re done.
Even checking job membership for a VM is easier with tags. Just have a look at its tags.
I will now show a simple example how to use tagged VMs in combination with Veeam Backup & Replication.
Continue reading “Using VM tags to manage backup SLAs”
Icons and stencils are very useful tools when building diagrams and presentations. They can help to simplify complex relations and workflows.
Ray Heffer (VMware) has published an entire set for Visio and PowerPoint. Icons are not official, but very nice.
Thank you very much. 🙂