XenCenter Storage Repository Rescan Issue – Solved

When clicking rescan on a storage respository in XenCenter, you may encounter an error like the one below.

rescan-failure

The problem is usually due to a foreign file in the storage repository. To find out what the offending file is, turn to the power of the command-line. Login to the master server and run the following command.
tail -n 100 /var/log/SMlog

Review the log and find the offending entry. It might look something like this.
***** VHD scan error: vhd=/var/run/sr-mount/3219ad4f-242e-1744-6d38-78e17efdce69/9411b73c-7a3a-4812-b64b-edfe8f04ee70.vhd scan-error=-32 error-message='opening file'

In this case, the file /var/run/sr-mount/3219ad4f-242e-1744-6d38-78e17efdce69/9411b73c-7a3a-4812-b64b-edfe8f04ee70.vhd could not be opened. After taking a quick look at that file, I quickly recognized that it was a 0 byte file. It did not create properly. I moved it out to the /tmp folder and tried to rescan. This resolved my issue.

Xenserver Heterogeneous CPUs in Pool

I have been working to get some Xenservers setup in the same pool that have different CPU versions. With different features, I get the error message that the CPUs are not homogeneous. To help rectify this, I created the following script and then followed the instructions below.

/root/get-cpu-features

#!/usr/bin/perl
$FEATURES2=$ARGV[0];
if (exists $ARGV[1]) {
        $FEATURES1=$ARGV[1];
} else {
        chomp($FEATURES1=`xe host-cpu-info | grep " features:" | cut -d':' -f2 | cut -d' ' -f2`);
}

if (!exists $ARGV[0]) {
        print "\nUsage: ./get-cpu-features [features-key1] [features-key2]\n\n";
        print "Local CPU Features: $FEATURES1\n";
        exit;
}

sub dec2bin {
    my $str = unpack("B32", pack("N", shift));
    $str =~ s/^0+(?=\d)//;   # otherwise you'll get leading zeros
    return $str;
}
sub bin2dec {
    return unpack("N", pack("B32", substr("0" x 32 . shift, -32)));
}

print "Local : ".$FEATURES1."\n";
print "Remote: ".$FEATURES2."\n";
$count=1;
@GROUP1ARRAY=();
@GROUP2ARRAY=();

foreach $GROUP1 (split(/\-/,$FEATURES1)) {
        my $GROUP1BIN=dec2bin(hex($GROUP1))."\n";
        my $GROUP1BINPADDED = sprintf("%033s", $GROUP1BIN);
        $GROUP1ARRAY[$count]=$GROUP1BINPADDED;
        $count++;
}

$count=1;

foreach $GROUP2 (split(/\-/,$FEATURES2)) {
        my $GROUP2BIN=dec2bin(hex($GROUP2))."\n";
        my $GROUP2BINPADDED = sprintf("%033s", $GROUP2BIN);
        $GROUP2ARRAY[$count]=$GROUP2BINPADDED;
        $count++;
}

@output=();

print "\nMerged: ";
for ($i=1; $i<=4; $i++) {
        $newgroup="";
        my @bin1=split(//,$GROUP1ARRAY[$i],33);
        my @bin2=split(//,$GROUP2ARRAY[$i],33);
        for ($j=0; $j<32; $j++) {
                $result=$bin1[$j]*$bin2[$j];
                $newgroup=$newgroup.$result;
        }
        $result=printf('%08x',bin2dec($newgroup));
        if ($i < 4) {
                print "-";
        }
}

print "\n";

On server 1

/root/get-cpu-features

The output will look something like this:

Usage: ./get-cpu-features [features-key1] [features-key2]

Local CPU Features: 0000e3bd-bfebfbff-00000001-20100800

On server 2, run the script again, but this time specify the key from server 1 as an argument to the script.

/root/get-cpu-features 0000e3bd-bfebfbff-00000001-20100800

Now the output will look like this:

Local : 0098e3fd-bfebfbff-00000001-28100800
Remote: 0000e3bd-bfebfbff-00000001-20100800

Merged: 0000e3bd-bfebfbff-00000001-20100800

The compatible feature key for all nodes is the one labeled merged, in this case, 0000e3bd-bfebfbff-00000001-20100800.

On each of the two nodes, we now need to set the feature key. We can do this by running this command on each node:

xe host-set-cpu-features features=0000e3bd-bfebfbff-00000001-20100800

Now reboot the nodes and then join them to the same pool.

Note: If you have more than two nodes, then you will need to add a second argument when running the script on nodes 3+. That second argument should always be the "Merged" key from each previous server that the script was run against. This will ensure that all nodes are accounted for in the final merged key. On the last node, the merged key that is produced will be the one that you need to use for every node.