EXT and LVM Local Storage in XenServer

On a new XenServer deployment EXT storage is default. Although EXT is nice (ability to manipulate raw VHD files and use sparse storage), LVM is faster and more stable. Here is how to switch between storage modes (be sure to back up all data first, as this will wipe everything in the repo):

Use ‘xe sr-list’ and ‘xe pbd-list’ to find your local storage SR and it’s PBD. Also note the physical device number / partition in the PBD, so you can re-create it on the same device later on.

Unplug the active SR’s PBD (physical block device):

xe pbd-unplug uuid=<pbd_uuid>

Destroy the SR:

xe sr-destroy uuid=<sr_uuid>

Create a new SR of the specified type and location:

xe sr-create content-type=user device-config:device=/dev/<device> host-uuid=<host_uuid> name-label="Local Storage" shared=false type=<lvm|ext>

You can verify the SR again with ‘xe sr-list’ and it should already be in XenCenter as the default.

Removing RAID metadata

Sometimes a hardware RAID controller or fakeraid (BIOS) can leave metadata that makes it impossible to install Windows or Linux, or it installs correctly, but causes a kernel panic or a 0xb7 blue screen error on the first boot. The only method I could find to delete the metadata *quickly* is to zero out the last 512KB of data on the disk using the following command:

dd if=/dev/zero of=$YOUR_DEV bs=512 seek=$(( $(blockdev --getsz $YOUR_DEV) - 1024 )) count=1024

Replace $YOUR_DEV with the physical device, such as /dev/sda

You could just zero the whole disk, but that could take hours. This command executes in less than a second.

Syncing User Filesystems Between Two Cpanel Servers

After doing a WHM multi-account copy, you may want to refresh the users home directories (including email and web files). This one liner uses rsync over SSH to do a quick sync of only changed files, emails, and website files. Run these commands on the NEW server.

First you need to create a list of domains in a text file ‘domains.txt’. Replace with the remote hostname or IP.

while read i ; do rsync -aHxv root@$(/scripts/whoowns $i)/ /home/$(/scripts/whoowns $i) ; done < domains.txt

Alternatively, you can use a list of users instead of domain names (use this method if there are multiple domains per user):

while read i ; do rsync -aHxv root@$i/ /home/$i ; done < users.txt

Syncing All MySQL Databases Between two Cpanel Servers

After you do a WHM multi-site transfer, you may want to resync all the MySQL databases before doing a DNS change. Here’s a quick and easy way to sync each Cpanel user’s databases on the new Cpanel server. After manually setting up a remote mysql root user on the original server (and opening a firewall port if needed), run this command on the NEW server.

cat /var/cpanel/databases/dbindex.db | grep -E ': .+' | awk '{FS=": ";print $1}' |[ \t]+|:)/, "")};1' | xargs -L 1 /root/sync_db.sh <remote_host> <remote_root_pass>

If you only want to sync (or resync) one or two databases, you can copy /var/cpanel/databases/dbindex.db to a different location and edit it as needed.

Here’s the bash sync script required for this command:


MySQL Relationships (JOIN explained)

The visual diagrams still confuse me after so many years and I always forget…so here it is:

INNER JOIN gets all records from one table that have some related entry in a second table

LEFT JOIN gets all records from the LEFT linked table but if you have selected some columns from the RIGHT table, if there is no related records, these columns will contain NULL

RIGHT JOIN is like the above but gets all records in the RIGHT table

FULL JOIN gets all records from both tables and puts NULL in the columns where related records do not exist in the opposite table

Pacemaker / Corosync / DRBD Cheatsheet

Monitor the status:


Migrate all resources to another node:

crm resource migrate rg_main <fqdn_node_name>

Take node offline and online (be careful, this sets a ‘prefer’ to the other node to force a transition, which may or may not get removed afterwards):

crm node standby
crm node online

Start and stop all resources (warning, this will take them completely offline, NOT migrate):

crm resource stop rg_main
crm resource start rg_main

Show configuration:

crm configure show

If resources are stuck in ‘(unmanaged) FAILED’ state, e.g. due to a failed stop action, you can clear it out:

crm_resource -P
crm resource cleanup rg_main

Be careful — this could trigger a migration if the stuck resources were preventing one. Make sure you’re ready for one.

Monitor the cluster status along with fail counts:

crm_mon --failcount

One-shot status output:

crm status

Check DRBD status:

cat /proc/drbd

DRBD split-brain cleanup on secondary node:

drbdadm disconnect main
drbdadm -- --discard-my-data connect main

DRBD split-brain cleanup on primary node:

drbdadm disconnect main
drbdadm primary main
drbdadm connect main

Scheduler optimizing on large arrays (untested):

echo deadline > /sys/block/sdb/queue/scheduler
echo 0 >  /sys/block/sdb/queue/iosched/front_merges
echo 150 > /sys/block/sdb/queue/iosched/read_expire
echo 1500 > /sys/block/sdb/queue/iosched/write_expire