Xenserver 7 NUC Fail Resolution

Learn this one weird trick your vGPU's don't want you to know

6 June 2016

Last time I talked about how my clean install and update experience with Xenserver 7 left me with a very broken XAPI.

I decided this weekend that I would take a harder crack at the problem and see if I couldn’t dig up a solution on my own. I ran into a twitter post from someone who claimed that not only did XS 7 work on his 5i5RYH, but also on the 6i5syk, an even newer version of the hardware.

The data points indicated that I had an issue with my configuration. So I re-installed XS 7 clean-style, and just as before I had a non-functional management layer. This time I went line-by-line in the /var/log/xensource.log looking for the errors I remembered about division_by_zero, and what was going on around those lines.

I don’t have the text now, but what appeared to be happening was that XAPI was attempting to store hardware configuration about the box in a database. There are a few lines about the detection (“Intel Graphics 6000”) and then the error occurs. The backtrace listed 12 files, but the top of the stack was in

xapi_vgpu_type.ml in line 477

So I went to Github, found the project and file and had a look.

Yup, there’s our division

let vgpu_size = Constants.pgpu_default_size /// vgpus_per_pgpu in

A couple of lines higher vgpus_per_pgpu is defined. I didn’t bother really tracking down what the code was doing, but looked at some of the variable names and deduced that it was angry because of the size of something. RAM maybe?

So I went into the firmware and changed the allocation of RAM to the GPU from 64MB to 256MB. I rebooted, and lo, I had a working XAPI. I could invoke xe commands and everything.

Unfortunately, the system was still kinda broken. I issued

xe-reset-networking

While that solved a couple of issues, I had weird problems with SRs and iSCSI IQNs missing, so in the end I just did another clean reload.

At that point, everything just worked. I added my iSCSI SRs without issue, and imported the virtual machine metadata backup and got all of my config and disk bindings back without any trouble at all.

I’ve run into several “weird” Xenserver issues before, but I’ve always had the tools and information to solve all of them. This was definitely the most vexing, but I’m glad I got to the bottom of it and made the tiny change required to make the system happy. I could probably lower the memory reserve to 128MB, but I honestly don’t care enough to do so. 128MB/16384MB just doesn’t make it over the ‘care’ threshold.

I hope this helps you, if you arrive here from Google with the same issues I had.


by:
0meta Staff

(blog@0metasecurity.com)