echo "

Attaching a USB device to KVM that reconnects frequently

I was trying to flash a new firmware to my BT headset (Sena SMH5-FM) and found out that the device reconnects several times during the flash process. Since KVM forces the use of BUS and ID rather than VendorID:DeviceID and the ID increments by one every reconnect this never works more than one time. To work around this I made a solution using UDEV to force a connect/reconnect of the device in KVM everytime it is being connected/disconnected to/from the host.


First find out the name of your KVM machine, you can try this command to get only the name portion

ps -ef | grep kvm |sed -n -e 's/^.*\(-name \)/\1/p'| cut -f2 -d" "

Mine is called win2k12r2, albeit a Win10

Stop the VM and create the following file (if you already tried to flash and you have a device like mine that also changes the DeviceID a couple of times make more entries) -> replace Sena with a portion of the name or brand of your device (see output lsusb)

grep -B3 Sena /var/log/syslog | sed -n -e 's/^.*\(idProduct\)/\1/p' | sort | uniq

I got this as a result (I suppose they just change it twice and that the logic is xxxx becomes yxxx and one time they use a generic ffff)


The VendorID is always the same and for Sena it is 092b


Next I created a USB device xml for everyone of them under


<hostdev mode='subsystem' type='usb'>
<vendor id='0x092b'/>
<product id='0xffff'/>

and a UDEV rule to connect and disconnect them


ACTION=="add", ATTRS{idVendor}=="092b", ATTRS{idProduct}=="ffff", RUN+="/usr/bin/virsh attach-device win2k12r2 /etc/libvirt/qemu/hostdev-092b:ffff.xml"
ACTION=="remove", ATTRS{idVendor}=="092b", ATTRS{idProduct}=="ffff", RUN+="/usr/bin/virsh detach-device win2k12r2 /etc/libvirt/qemu/hostdev-092b:ffff.xml"
ACTION=="add", ATTRS{idVendor}=="092b", ATTRS{idProduct}=="cd65", RUN+="/usr/bin/virsh attach-device win2k12r2 /etc/libvirt/qemu/hostdev-092b:cd65.xml"
ACTION=="remove", ATTRS{idVendor}=="092b", ATTRS{idProduct}=="cd65", RUN+="/usr/bin/virsh detach-device win2k12r2 /etc/libvirt/qemu/hostdev-092b:cd65.xml"
ACTION=="add", ATTRS{idVendor}=="092b", ATTRS{idProduct}=="4d65", RUN+="/usr/bin/virsh attach-device win2k12r2 /etc/libvirt/qemu/hostdev-092b:4d65.xml"
ACTION=="remove", ATTRS{idVendor}=="092b", ATTRS{idProduct}=="4d65", RUN+="/usr/bin/virsh detach-device win2k12r2 /etc/libvirt/qemu/hostdev-092b:4d65.xml"


After this you can start your VM and try to flash your device, if it still fails check again to see if there are no extra DeviceID's in the syslog

Use Ansible to report which systems need to reboot

I created this cronjob using an Ansible playbook to see if any of the Ansible managed hosts are up too long or have a newer kernel installed than the one running. This gives us a monthly overview to see which machines should be rebooted. This script is only valid for RPM and Red Hat based systems. Please adapt root on the end of the cron line to match the e-mail address you want to send your report to and make sure the system mail service is configured correctly.


# Send a report mail every month with the ansible managed hosts that have an uptime equal or higher than 300 days OR have a newer kernel installed than the one running
0 0 1 * * sysauto /usr/bin/flock -x -n /opt/systems/ansible -c 'cd /opt/systems/ansible/ ; ansible-playbook playbooks/systems/check_uptime_and_kernel_upgrade.yml | grep " has " | sed -e "s/^[ \t]*//" | mail -E -s "Monthly report: Systems that need a reboot" root'


- hosts: all
- name: "Check for machines that have an uptime that exceeds 300 days"
shell: echo "$(hostname) has been up for $(uptime | cut -d ',' -f 1 | cut -d ' ' -f 4) days"
when: ansible_uptime_seconds > 25920000
register: uptime_exceeded
- name: "Check for machines that aren't running the latest installed kernel"
shell: LAST_KERNEL=$(rpm -q --last kernel | perl -pe 's/^kernel-(\S+).*/$1/' | head -1);CURRENT_KERNEL=$(uname -r);test $LAST_KERNEL = $CURRENT_KERNEL || echo "$(hostname) has a newer kernel installed than the one running"
ignore_errors: true
register: reboot_hint
- debug: var=uptime_exceeded.stdout_lines
- debug: var=reboot_hint.stdout_lines


Zimbra to Zimbra migration using Zextras and SSHFS

This is only an extension to a normal installation. So you should have your new Zimbra environment ready to move the data of your current Zimbra environment to it.

In the past we did an in-place upgrade of our Zimbra and the Ubuntu it was residing on. The last upgrade from 8.5.1 on Ubuntu 14.04 to 8.7.1 on Ubuntu 16.04 was such a drama that I started looking for an easier solution that would give me a fresh Zimbra with all my settings, accounts, mails, calendar items ... without too much fuss.

To prevent inconsistency please stop your old Zimbra and afterwards make a snapshot and/or backup before you continue.

/etc/init.d/zimbra stop


su - zimbra -c "zmcontrol stop"

Also stop and disable fetchmail if you're using it

/etc/init.d/fetchmail stop 
sed -i "s/START_DAEMON=yes/START_DAEMON=no/g" /etc/default/fetchmail

Next change the IP because the Zimbra will need to be started again to do the export

sed -i "s/old_ip/temporary_ip/g" /etc/hosts /etc/network/interfaces

Next on both Zimbras create a folder to store the migration data on

su - zimbra -c "mkdir /opt/zimbra/backup/exports /opt/zimbra/backup/zextras"

Next mount this folder as the user zimbra on the new Zimbra (don't set a password on the zimbra user, just create a key pair and share the SSH public key). This will save you time to move the data.

 sshfs zimbra@temporary_ip:/opt/zimbra/backup/exports/ /opt/zimbra/backup/exports/

Next install the migration tool on the old Zimbra

cd /tmp && wget
tar xvzf zextras_migration_tool-*.tgz
cd zextras_migration_tool-*/
./install all

Now open the Zimbra admin page (https://temporary_ip:7071) and start exporting the domains and user you want to keep. Through ZeXtras -> ZxMig -> Start Migration



 Change the folder to the newly created /opt/zimbra/backup/exports


Select the domains you want to move


Under ZxNotifications check for any error during the export


When this finishes you can start importing on the new Zimbra. First install the Zextra suite (this is free for 30 days and we will remove it after we finish to get rid of warnings afterwards)

cd /tmp && wget 
tar xvzf zextras_suite-*.tgz
cd zextras_suite-*/
./install all

Open the Zimbra admin page (https://new_ip:7071) and open the ZeXtas -> ZxBackup -> select Import Backup


Change the path to /opt/zimbra/backup/exports


Select the domains you want to import


Select the accounts you want to import


And check if the restore started without warnings


After this finished you can clean up and give your new Zimbra the IP of the old one to start sending and receiving mails again.

If you had an SSL certificate installed now is the time to move that as well. Do this as user zimbra!

On the old zimbra

rsync -au /opt/zimbra/ssl/ zimbra@new_ip:/tmp/ssl/

On the new Zimbra

cp /tmp/ssl/zimbra/commercial/commercial.key /opt/zimbra/ssl/zimbra/commercial/ 
./zmcertmgr deploycrt comm /tmp/ssl/zimbra/commercial/commercial.crt /tmp/ssl/zimbra/commercial/commercial_ca.crt

In any case I would also enable HTTP -> HTTPS redirection

zmprov ms "FQDN" zimbraReverseProxyMailMode redirect

Let's finish:

FIRST: shutdown the old Zimbra machine and make sure it won't boot by itself. Don't forget to copy any backup settings, fetchmail config, cron jobs, ...

On the new Zimbra

cd /tmp/zextras_suite-*/ 
./install -u all
sed -i "s/new_ip/old_ip/g" /etc/hosts /etc/network/interfaces

Now your new Zimbra should be available with all the settings, accounts and mails just like it was when you stopped your old Zimbra.