If you are old enough to remember QEMM from back in the ’90s, along with other tools we used to squeeze every last byte of memory under the 640KB limit, you may remember a rather cool feature it had – warm reboot.
What is a Warm Reboot?
Reboot involves the computer doing a Power-On Self Test (POST). This takes time, often as much as a few minutes on some servers and workstations. While you are setting something up and need to test frequently that things come up correctly at boot time, the POST can make progress painfully slow. If only we had something like the warm reboot feature that QEMM had back in the ’90s, which allowed us to reset the RAM and reboot DOS without rebooting the entire machine and suffer the POST time. Well, such a thing does actually exist in modern Linux.
kexec allows us to do exactly this – load a new kernel, kill all processes, and hand over control to the new kernel as the bootloader does at boot time. What do we need for this magic to work? On a modern distro, not much, it is all already included. Let’s start with a script that I use and explain what each component does:
Let’s look at the kexec lines first. uname -r returns the current kernel version. $(uname -r) bash syntax allows is to take the output of a command and use it as a string in the invoking command. On recent CentOS 8 here is what we get:
This is the minimum needed to boot the kernel. Once we have supplied this information, we initiate the shutdown and process purge, and hand over to the new kernel, using:
But what are the systemctl and rmmod lines about? They are mostly to work around finnickiness of Nvidia drivers and GPUs. If you execute kexec immediately, with the Nvidia driver still running, the GPU won’t reset properly and won’t get properly re-initialised by the driver when the kernel warm-boots. So we have to rmmod the nvidia driver. Legacy nvidia driver only includes the nvidia module. Newer versions also include nvidia_drm, nvidia_modeset and nvidia_uvm which depend on the nvidia module, so we have to remove those first. But before we do that, we have to make sure that Xorg isn’t running, otherwise we won’t be able to unload the nvidia driver. To make sure graphical environment isn’t running, we switch the runlevel target to multi-user.target (on a workstation we are probably running graphical.target by default). Once Xorg is no longer running, we can proceed with unloading the nvidia driver modules. And with that done, we can proceed with the warm boot and enjoy a reboot time saving.
I recently put in place Google Adwords for my colleagues, at the MySQL Consultancy, Shattered Silicon, and there are a few things that I think anyone using Google Adwords for advertising products and services should know in order to avoid wasting any of their marketing budget. All of these things are pretty obvious in hindsight, but if you dive in with no experience, you will likely find yourself wasting a lot of your marketing budget on advertising to an audience that isn’t looking to buy.
Location, Location, Location!
Advertise only in places where the companies can plausibly afford to engage your services. In broad terms, this means that if you are based in and doing business from an OECD country, unless you operate in a niche that bucks this rule, there is a good chance that clients who aren’t in another OECD country – can’t afford you. So make sure you set your advertising campaign to specifically target the countries that are of interest to you and specifically exclude the countries that are not. Of course this is not a hard rule – there could be benefit to including additional countries, e.g. if you have staff who speak the language.
There is another aspect of this – in countries where the economy isn’t doing great, there are more likely to be people looking for work in the industry you operate in who will click your advert on the off chance that you may be hiring. So unless you are struggling to hire remote workers, this is another reason to focus on locations where those expensive clicks are likely to be bringing you visits from prospective clients, rather than prospective employees or competitors.
Which brings us onto the next point.
Exclude Job-Seeker Terms
Unless you are looking to hire, exclude commonly used job-seeking terms, such as “hire”, “junior”, “senior”, “internship”, “training”, “position”, “opening” and any others you can think of. This significantly reduced the number of impressions and clicks which were never going to turn into sales.
Avoid Ambiguous Terms
It is worth investing some time into researching whether there there is a tool with a similar name to the service you are offering. For example, if you are advertising services of a MySQL administrator, you may find that most of the clicks you get are from people looking for the deprecated tool of the same name. Similarly, either avoid your advertising of MySQL tuning services or disambiguate it from the MySQL tuning tool.
Ideally, try to avoid such term completely or at the very least use specific rather than broad matching and add exclusions for the words used in things other than what you are trying to market.
Presumably, if you are spending your hard earned money on marketing to grow your business, you are running a commercial operation rather than a charity. So you should probably exclude terms like “free”, “trial”, “download” and other terms typically used in searches for things that people don’t expect to pay for.
Another very obvious optimisation, when you think about it, is optimising by age range. If you are selling a highly technical service service aimed at business owners and CTOs, it is unlikely they will be younger than mid-20s or older than the retirement age. So exclude those age ranges from your advert targeting spec.
Use the Price Extension on your Advert
You may think that showing prices of 2-3 of your most popular products puts people off from clicking on your ad, but this is a good thing. If a price tag puts somebody off from your advert, there is a good chance they aren’t looking to buy anyway – so they might as well not cost you for the clicks.
Effect on Impressions, CPC and CTR
If you are doing it right, you will find that your total conversion cost will go down, but at first look counter-intuitively, your CPC will go up and your impression count will go down – because your competitors have already probably already gone through a similar exercise, and you are homing in on the actually valuable impressions that they are also competing for. The CPC in the case I have been working on almost doubled overnight once I applied all of the above optimisations. But the cost per conversion went down overall.
Hopefully, these thoughts will get your marketing efforts off to a smoother and cheaper start than it would have otherwise been.
I recently pressed a G7 MicroServer back into service, and disccovered that I couldn’t connect to it over SSH. This seemed odd given that I am quite certain I remember doing so before. A quick nmap scan showed that the ssh port was definitely open on the ILO:
Starting Nmap 6.40 ( http://nmap.org ) at 2020-06-07 23:06 BST Nmap scan report for 192.168.0.2 Host is up (0.0086s latency). Not shown: 992 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 111/tcp open rpcbind 427/tcp open svrloc 443/tcp open https 2068/tcp open advocentkvm 5988/tcp open wbem-http 5989/tcp open wbem-https
Increasing verbosity on ssh connection (ssh -v), yielded some interesting insight, specifically:
debug1: match: OpenSSH_5.2 pat OpenSSH_5* compat 0x0c000000
So it could in fact be that more modern ssh tries to connect with ciphers and protocol options that the now relatively ancient OpenSSH 5.2 doesn’t quite understand. So I quickly grabbed OpenSSH 5.2 portable, built it and tried with that, and – success! Doing it again with verbosity turned up showed what ciphers and MACs were used. I added the following to my ~/.ssh/config:
Host 192.168.0.2 Ciphers aes128-ctr MACs hmac-md5
And lo and behold, ssh-ing to the ILO from recent ssh on EL8 now works!
Hopefully this will save somebody some time in the future, or prevent them from throwing away what is still a perfectly usable microserver.
I had the misfortune the other day that one of my machines updated beyond 1809 release. There are three changes that immediately infuriated me.
1. Colour scheme change and removal of availability of black colour menus
The colour scheme changes upon upgrade. Not only is it a rather bright one going back to the ’90s style and contrary to dark themes that are easier on the eyes, laptop batteries and screen burn, but there is no way to full revert back. In order to get anywhere near black it is now necessary to disable the transparency effects, and even then it is still not black but dark grey.
Visually, this is a huge downgrade that cannot be fully mitigated or undone. And a bit of googling will show that I am far from the only one infuriated by this change.
2. File explorer grouping by default instead of continuing with previous default
As soon as you open your file folders after the upgrade, the files are now grouped by default. I can understand that this might be a new default setting, but on an upgrade, old behaviour should be preserved. If somebody chose not to view their files grouped, they should not be overriden by the upgrade and made to waste their time putting things back the way they were. Worse, this seems to revert the the new annoying default randomly.
Microsoft needs to understand that the ONLY reason why anyone uses Windows instead of a different operating system is long term inertia of familiarity. Chipping away at that familiarity will just push more users away from Windows and toward other operating systems. This is user alienation by a million paper cuts.
3. Start menu auto-expand
This one is incredibly annoying for a change so minor. There is supposedly a way to disable this using the mach2 tool, but it doesn’t seem to have worked for me – no matter what I do, I couldn’t get it to turn off and stay off.
So what did I do? Well, this is a VM – I refuse to run Windows on bare metal since over a decade ago, because it is too prone to getting itself into a state where various things break in a way that all the googlable solutions just don’t work and the only solution is to format and reinstall (windows update getting broken is a common show stopper). Being a VM, it doesn’t run on a real disk but a virtual one. I run my VMs on ZFS zvols, which are regularly snapshotted. So I powered off the VM, performed a zfs rollback to a pre-upgrade snapshot, and as if by magic, all of the damage done by releases after 1809 have been undone and things are back in a state where at least the new annoyances are gone. Best of all, zfs rollback took a few milliseconds instead of the lengthy rollback using Windows restore that probably wouldn’t have put things back quite to exactly the same state the machine was in before.
The upgrade will no doubt be forced on me at some point, in a way that I can’t avoid it any more. The feature upgrades can only be postponed by 365 days and disabled for another 30. But at least – today is not that day.
Plea to Microsoft
Please, for the love of God, stop changing things in ways that nobody asked for, nobody wanted, and nobody likes. Make your designers and developers learn from the fiasco of the ribbon interface.
A long time ago, I posted an article about advantages of hardware accelerated SSL encryption, and how to get it working on Fedora Linux. Since then, some things have improved, and some things have regressed.
RedHat have broken OpenSSH with their audit patch. This is particularly inconsistent with the fact that the distro supplied openssh package in EL6 is built with the –with-ssl-engine option, to enable support for hardware crypto acceleration, yet this is clearly completely untested, which begs the question of what the point of it is.
Thankfully, the regression mentioned above can be fixed to make sshd work properly with hardware crypto offload.
Here are links to patched OpenSSL and OpenSSH packages for EL6, current at the time of writing this article:
While ssh with using the blowfish algorithm in software is very fast and good enough for general purpose ssh usage, for some operations, such as transferring ZFS snapshots over ssh, using hardware offloaded AES provides a very welcome performance boost, because it leaves more CPU available for other processes.
The last official release of zfs-fuse was years ago, and it was seriously starting to fall behind other implementations. It was effectively abandoned, which is quite inconvenient considering it is still the only viable option on 32-bit Linux installations (e.g. on ARM or those who are still tied to i686 for legacy reasons).
Since I use Linux on ARM heavily, I have been working on changing this for the past few weeks. The last official release 0.7.0 was made by Seth Heeren a few years ago, and this supported ZFS pool versions up to v23. Emmanuel Anne was maintaining an unofficial post-0.7.0 branch that had support for pool versions up to v26 added. Over the past couple of years, other people have contributed a few patches here and there (manual ashift setting at boot time, some patches to add support for ARM, a couple of patches maintained out of tree shipped with the Fedora package). Over the past few weeks I need a few additional features that have existed in other implementations, particularly for running a root file system on it (mount.zfs for legacy mount points, and better systemd/initramfs), so I added those features. It also transpired that a few of the patches that made it into the official 0.7.0 release weren’t in Emmanuel’s code tree since it was forked before the official 0.7.0 release. I located and backported those from Seth’s maint branch on github.
With all this done, and with no other volunteers showing any interest in further maintaining zfs-fuse, it seems to have fallen to me to make the decision to take the 0.7.1 release. I have tested this extensively on my ARM systems with pools of various sizes (16GB to 16TB) and complexities (single disk to RAIDZ2) and it has been very stable.
If you are stuck on a 32-bit Linux platform and would love the features of ZFS, you can find the latest release of zfs-fuse on on github:
Future work will include adding support for additional pool versions. I have already created branches for those, but, this will need extensive testing before I deem it stable enough for a release. If you are interested in helping with either development or testing of zfs-fuse, please, do get in touch.
Having used the EVGA’s once flagship and possibly their most hyped up ever motherboard for the past two and a half years and having fought it’s many bugs and quirks extensively over that period through many uses it was supposed to, in theory, be capable of but was clearly never tested against, it seemed like a good idea to collate all the issues and workarounds into a single article. These findings have been cross-checked against multiple SR-2 motherboards.
Hardware / BIOS / POST
While there are various minor annoying bugs in the BIOS itself, I will not go into details of those and instead focus on the issues of real practical use
96GB of RAM
Xeon X5xxx series CPU specification states that each is capable of addressing 192GB of RAM. Unfortunately, EVGA SR-2 specification only states it is capable of handling up to 48GB of RAM. This is more than a little disappointing, but there is a way to persuade it to complete the POST with 96GB with 12 8GB DIMMs. You will need 12 8GB x4 dual-ranked registered DDR3 DIMMs. Insert 6 of them into the red memory slots, and boot up. Set the following:
MCH strap: 1600MHz
Memory speed: 1333
Manually set all the memory timings to what they were auto-detected to be
Set the command rate to 2T
No voltage increases are required just because you have 96GB – if your DIMMs are rated at 1.35V, then there is no need to set DIMM voltages higher than 1.35V.
Insert the remaining 6 DIMMs and it should now be able to boot with 96GB. The POST may take 2-3 cycles to complete, but within 30 seconds or so you should see the BIOS splash screen. Once it has booted up, a soft reboot will complete without delay. It only takes a little while on a cold boot.
Don’t expect 96GB to POST at much over 167MHz BCLK.
Unfortunately, more than 96GB will not work.
Watch out for SpeedStep Side Effects
If you enable SpeedStep but disable TurboBoost, the CPU will still boost to +1 multiplier. This is not intuitive and can cause you problems during stability testing.
Clock Generator Stability
Above 180MHz BCLK, expect to see very noisy clock signals. If you watch the clock speeds on a monitoring application, you will notice that the clock speeds will regularly spike very high and very low. This means that the stability above 180MHz BCLK is not going to be appropriate for any serious use.
Virtualization With VT-d / IOMMU
All the PCIe slots on the SR-2 are behind Nvidia NF200 PCIe bridges. Unfortunately, these have a bug in that they do not route all DMA via upstream root PCIe hub. The consequence is that when a virtual machine with PCI passthrough tries to access memory at physical range within it’s virtual sandbox that overlaps with the physical range of a PCI IOMEM area mapped to any physical device, this will be routed to the physical device rather than remapped out of the way. When this happens, at best it will result in a host crash when a physical card crashes and takes the PCIe bus down with it. At worst, the memory access will trample the region mapped to a disk controller which can easily result in garbage being written to disk – and then the host will crash anyway.
To workaround is to make sure by whatever means are available that the virtual machine does not access the area between 1GB and 4GB, which is the area reserved for mapping PCI I/O memory. Two years ago the only solution available to me was to write a patch for Xen’s hvmloader that marked that entire memory area as reserved. In theory you could also tell your guest OS to simply not use that memory (e.g. using bcdedit in Windows 7 and later to mark the area as badmem, or using mem= parameters to the Linux kernel). Today with the latest version of QEMU for Xen and KVM, you can instead use the max-ram-below-4g=1G parameter to the -machine option, which will achieve the same thing much more cleanly and with no ill side effects (such as 3GB of RAM going missing in the guest).
Note that even with this workaround, there will still be weird seemingly DMA related crashes on the SR-2 when you have VT-d enabled and you use SAS controllers. For some reason this motherboard really does not play well with them (tried three different generations of LSI, an Adapted and a 3Ware). Some controllers will simply have no disks show up when you boot the kernel with intel_iommu=on (older LSI, Adaptec), others will seem to work but randomly crash when a VM with PCI passthrough is running (3Ware). Simple SATA controllers do not seem to suffer from this problem.
Marvell 88SE9123 SATA-3 6 GBit controller
This may nominally be a 6GBit/s SATA controller, but you should be aware that its physical upstream connection is via a x1 PCIe 2.0 lane, with a maximum throughput of 5GBit/s. That means the maximum throughput you can possibly get from both of these SATA ports (the red ones on the board) combined is about 450-500MB/s. This is something to bear in mind if you are planning to connect a pair of SSDs. You will achieve higher overall throughput by connecting the 2nd SSD to the ICH10 SATA-2 controller (the black ports on the board), even through the latter only supports up to 3GBit/s.
Overclocking with Westmere Xeons
The settings I have used with great success for the past 2.5 years, in addition to those mentioned above required for operation with 96GB of RAM are:
CPU Core Voltage: 1.300V. This is sufficient for up to 4GHz. You may need to go as far as 1.350V for 4.15GHz, but beyond that no voltage increase will keep things stable.
VTT Voltage: 1.325V. This is sufficient up to about 3.33GHz uncore speeds, which is about as far as you can realistically expect to get out of Westmere Xeons. Do not under any circumstances push this past 1.350V as it is almost guaranteed to damage the CPU regardless of how good the cooling is.
BCLK: <= 180MHz. My experience is that this is as far as you can go before clock frequencies start to spike all over the place. In the interest of stability, I would recommend not exceeding 177MHz, as this is where 4.8GT/s QPI setting actually equals 6.4GT/s that all the components are rated at – and there seems to be almost no headroom at all for QPI overclocking on components of this generation.
Motherboard Heatsink Fan
As far as I have been able to establish, this only seems to make any appreciable difference in cases of combined extreme BCLK overclocking, IOH over-volting, and using most if not all of the 64 PCIe lanes available through the PCIe slots. In more typical use (two PCIe x16 GPUs, 166MHz BCLK, relatively low 1.250V on the IOH), the difference between the fan being full on (approx. 5000 rpm) and completely off is around 9C (46C fully on, 55C completely off). Consequently, it may be preferable in some cases to remove the aluminium duct plate surrounding the fan, disconnect the fan, and leave the heatsink to passively cool the Intel 5520 I/O Hub, Intel ICH10 South Bridge, and Nvidia NF200 PCIe bridges. The airflow through the case caused by the case fans is likely to be more than sufficient in most if not all installations. This will also prevent the sometimes extreme yet invisible dust build-up in the fins on this heatsink under the aluminium duct plate surrounding the fan causing the temperatures to be higher than they would be if there were no active fan or duct plate present.
This will show up as soon as you start the installer for any distribution you choose. You will receive a flood of messages to the console which will make the system grind to a halt. The workaround is to add pcie_ports=compat to the list of kernel boot parameters. Unfortunately, there is a device on-board that is erroneously marked as hot-pluggable and results in ASPM causing to flap between plugged and unplugged states. Disabling ASPM in the BIOS is not sufficient to fix this.
Intel HD Audio Line Mapping
This took me a while to work out, and had me thinking I had a failed audio port. The front panel connector is using an unusual port, resulting in it not producing output, and not even emitting ACPI events when something is connected and disconnected. The solution is to produce a correct map and supply it to the driver (it turns out problems like this are so common that the snd-hda-intel driver can load such a map at startup.
Simply put this in /lib/firmware/hda-jack-retask.fw:
Unfortunately, it took many man-days over the past two years to work out all this, and work out the solutions. It is not acceptable that a high-end flagship product of the sort that the SR-2 was presented to be is so buggy and require so much troubleshooting from the end customer. While the SR-2 has it’s place in history as the board that allowed for overclocking Xeons, along with the gems from a long time ago such as the A-bit BP6 which allowed dual socket operation with Celerons, in the time it took to work around all of it’s bugs it is unfortunately already deprecated, discontinued, and unsupported, and the top of the line Xeons X5690 processors are selling for little enough in the second hand market that the gains simply do not justify the effort, as appeared to be the case 2-3 years ago when starting with the several times cheaper X5650 processors.
In retrospect, when the effort is accounted for, a similar build using a pair of X5690 Xeons and a Supermicro X8DTH-6F motherboard would have almost certainly been a cheaper and less problematic experience. It might not have any overclocking functionality, but while offering the same number of PCIe x16 slots (7) and memory sockets (12), it does support 192GB of RAM (4x more than the SR-2 in the same number of sockets) without any special undocumented approaches required to make it work, and comes with an 8-port SAS controller on-board, while suffering from none of the problems above. Something that just works is usually much more economical than something that ends up requiring many days of troubleshooting effort.
In the previous article in this series, I detailed the journey to my original configuration with a single host providing multiple gaming capable virtual machines as a multi-seat workstation. But things have changed since then – many game distribution platforms such as Steam, GOG and Desura have native Linux versions, and many games have been ported to run natively on Linux. The vast majority of the ones that haven’t now work perfectly under WINE.
Consequently, the ideal solution has changed as well. In the original configuration, there were 3 seats on the system – two Windows VMs for gaming and one Linux VM for more serious use. At least one of the Windows VMs could now be removed, and it’s functionality replaced with WINE and native ports.
At the same time KVM advanced greatly in features and stability, and is now much better aligned with the requirements of this multi-seat workstation project. Perhaps most importantly, the latest QEMU even provides a feature that provides a much better workaround for the issue I had to patch Xen’s hvmloader for: max-ram-below-4g (option to the -machine parameter). Setting this to 1GB comprehensively works around the IOMMU compatibility bug of the Nvidia NF200 PCIe bridges on the EVGA SR-2, without any negative side effects.
Even better, KVM also includes patches that neuter the Nvidia driver’s ability to detect it is running in the VM (add kvm=off to the list of options passed to the -cpu parameter). That means that modifying the GPU firmware or hardware to make it appear as a Quadro or Tesla card is no longer required for using it in a virtual machine. This is a massive advantage over the original Xen solution for most people.
Windows 7 VM now uses UEFI instead of legacy BIOS This does away with all of legacy VGA complications such as VGA arbitration and the UEFI OVMF firmware even downloads and executes the PCI devices’ BIOS during the VM’s POST, which results in the full splash screen and even UEFI BIOS configuration menus being available during the VM boot on the external console.
XP x64 VM removed Superseded by using native Linux game ports and WINE for the rest (so far every XP compatible game I have tried works)
Some of the extra repositories I used for this are:
The reason for the qemu:commandline section is that libvirt and especially virt-manager do not actually understand all possible QEMU parameters. The ones that they don’t support directly are in this section to avoid errors and complaints from virsh and virt-manager in normal use.
You may also notice that there are some unusual sections and values in there, so let me touch upon them in groups.
Windows Activation and Associated Checks
When you first activate Windows with a key, it keeps track of several important details of the hardware in order to detect whether the same installation has been moved into another machine. Most licenses (e.g. OEM ones) are not transferable to another machine. So in order to ensure that our installation is portable (e.g. if we upgrade to a different hypervisor at a later date), we set the various values to something static, easily memorable and predictable, so that if we ever need to migrate the VM to another host, it will not cause deactivation issues. The important settings are here (these are not in all cases complete sections, only the fragments required for this purpose, see above for the full configuration):
The following sections are required in order to work around the NF200 PCIe bridge bugs (max-ram-below-4g=1G) and the Nvidia driver feature that disables GeForce GPUs in virtual machines (kvm=off):
The reason this is important is because most non-server editions of Windows only allow up to two CPU sockets. By default QEMU presents each CPU core as being on a separate socket. That means that no matter how many CPUs you pass to your Windows VM, while they will all show up in Device Manager, only a maximum of two will be used (you can verify this using Task Manager). What the above configuration block does is instruct libvirt to tell QEMU to present four cores in a single CPU socket, so that all are usable in the Windows VM.
VFIO and Kernel Drivers
In my system I have two identical Nvidia GPUs. Numerically, the second one is primary (host), and the first one is the one I am passing to a virtual machine. I am also passing the NEC USB 3.0 controller to the VM. This is the script I wrote (in /etc/sysconfig/modules/) to bind the devices intended for the VM to the VFIO driver:
Note that the PCI bus IDs will change if you add more hardware to the machine – that is why I wrote this script, rather than assigned the devices statically by ID. The above script works for me on my hardware – you will almost certainly need to modify it for your configuration, but it should at least give you a reasonable idea of the approach that works.
Important: The devices this identifies have to match what is in your libvirt XML config file in the relevant hostdev sections. You will have to adjust that manually for your configuration, either using virsh edit or virt-manager.
Also depending on your hardware, you may need to do the initial Windows installation on the emulated GPU rather than the real one (e.g. if you are using a USB controller for the VM that requires additional drivers, as is the case with the USB 3.0 controller I am using for my VM). Otherwise you will get display output but be unable to use your keyboard/mouse during the installation.
Gaming on Linux: Steam
Pre-packaged Steam binary used to be available form the rpmfusion repository, but this no longer appears to be there. Thankfully, there is also a maintained negativo17’s repository for Steam for Fedora 20+, which installs and runs fine on EL7. You may also need to grab a few RPMs from Fedora 19 because EL7 doesn’t ship with a full complement of 32-bit libraries. The ones I found I needed are these:
The reason these are from Fedora 19 is because F19 is virtually identical in terms of package versions to EL7.
Typically, the Steam RPM installation is a one-off, mostly to bootstrap the initial run, and install the dependencies. After that, a local version of Steam will be installed in the user’s home directory in ~/.local/share/Steam/. In light of the recent Steam bug resulting in deletion of the user’s entire home directory, I implemented a solution that runs Steam as a separate steam user, from that user’s own home directory. That way should anything similar to this ever happen, the only thing that would be deleted is the steam user’s home directory rather than any important files not related to running Steam games.
To do this, you will need to add a steam user, and give it necessary permissions:
From there on, when you invoke steam.sh, it will launch steam as the steam user, and pass the graphical output to the Xorg session of the logged in user. The net result is that any potentially damaging bug in Steam or associated games can only do damage to the files owned by the steam user. This security model is not dissimilar to the Android security model where every application runs under it’s own user, for similar security reasons.
2) More traditional WINE (I use the one from DarkPlayer’s repository)
I only had to make one configuration change to WINE, and that is to disable the dwrite.dll library in WINE (to disable it, run winecfg, go to Libraries -> add dwrite.dll, edit dwrite.dll entry and set it to disabled). I am using XP version emulation, which isn’t even supposed to include dwrite.dll, and the problem it causes is that fonts are invisible in Steam and some other applications.
The end result is a much cleaner virtual machine configuration: e.g. no missing RAM like before with Xen, due to the NF200 bug workaround, and no need for hardware modification of my GeForce cards. The performance seems very smooth, and so far the entire setup has been completely trouble free.
There is also one fewer virtual machine and one fewer GPU in the system without any loss of functionality. Should I require an additional seat in the future, it will most likely be a Linux one, and implemented using a Xorg multi-seat configuration.
For about two years now I have managed to stick to the “No Windows on bare metal.” policy. This was instated for many reasons, including security and ease of backups (it is difficult to beat ZFS snapshots and send/receive functionality). The key reason for using Windows at all has been gaming, and both myself and my wife do play various games, mostly of the co-op FPS genre. While native Linux support has increased dramatically in that time, the availability of native Linux games still hasn’t quite reached parity with availability on the Windows platform.
Combining the “No Windows on bare metal.” policy with the requirement for high performance gaming capability meant that the only solution that fits is PCI passthrough of a high end GPU to the virtual machine. In this article I will describe the journey to the solution over the past two years, including (often unfortunate) choices of hardware, software, working around hardware, firmware, driver and software bugs, crippling and limitations, and other bumps on the road to virtualized gaming.
When I first embarked on this project, it was an off-shoot of the project to upgrade my workstation. While there was nothing wrong with my Quad Core 2 in terms of performance, I needed to get a second machine up and running for my wife. So, somewhat optimistically, I thought this would be an ideal opportunity to solve three problems at the same time:
Get a gaming grade workstation up and running for my wife
Virtualize the Windows part of my dual-boot setup so I never have to reboot for the sake of joining a game when my friends invite me
Implement the “No Windows on bare metal.” policy
The motherboard that caught my eye was the EVGA SR-2. It seemed to fit all of the necessary requirements:
Plenty of CPU power (dual socket, capable of taking up to two 6-core Xeons)
Full support for plenty of ECC memory (after the last build I have vowed to never build another machine without ECC RAM, having spent days troubleshooting a stock-setting stability issue that turned out to be marginal memory)
Plenty of PCIe slots (7 x16 slots, with 64 usable PCIe lanes between them)
VT-d support (originally listed in the spec, and confirmed with EVGA tech support prior to purchase – a claim that turned out to be rather stretching the truth)
A sizable investment into the motherboard, a pair of 6-core X5650 Xeons, and 48GB (6x8GB) of registered ECC RAM later, problems began.
The first motherboard I got turned out to have a faulty PCIe slot #1. The retailer I bought the motherboard from went bust a few weeks after my purchase, but EVGA generally have excellent RMA service, and I registered the motherboard as soon as I had received it to qualify for the full 10 year manufacturer’s warranty that was offered on this motherboard.
In order to not put my build on hold, before I RMA-ed the faulty SR-2, I bought another, second hand SR-2 on eBay. I thoroughly tested it, and to this day, this is the SR-2 that has been completely fault free in the main workstation that was the product of this project. It turns out, I was quite lucky to have bought a second motherboard – because the replacement that was sent was also faulty, and failed to reliably finish POST-ing with either of my CPUs in either socket. That got RMA-ed as well, and the replacement is currently in use as a prototyping rig for the next incarnation of this workstation, but that motherboard also has problems which cause it to fail to boot on a hot reboot (I am putting off RMA-ing it until the prototyping stage of the project is completed and being without a working prototyping machine for a week won’t be a problem.
In conclusion: Beware EVGA warranty replacement motherboards – they are all refurbished items that were sent back as faulty, and either repaired or the fault was never reproducible by their testing team so they got recycled as is. Always test any refurbished replacements extremely thoroughly (all slots, sockets, ports and features) when you receive them – if you get a faulty replacement, EVGA will pay for the shipping costs back to them for another replacement, but only within the first month after you receive the replacement, so acting quickly and thoroughly is of vital importance to avoid courier costs that can quickly add up to a lot.
At this time I looked into using 96GB of RAM on the SR-2. This turned out to be very difficult as the machine would generally refuse to POST, except after a fresh CMOS reset. This was particularly annoying because the CPUs themselves (which contain the MCH) officially support 192GB of RAM each. After a lot of trial and error, I found a way to make the machine reliably post with 96GB of RAM:
Boot the machine with only 6 DIMMs. Go to the memory settings, and manually set all of the memory timings to what they defaulted to. Make sure you set the command rate to 2T (defaults to 1T).
If you are overclocking, make sure you set the MCH strap to 1600MHz.
Do this and your SR-2 should POST with 96GB. It may require a few attempts where the motherboard re-sets itself and re-attempts the POST, but both of mine successfully POST within 30 seconds.
All of the symptoms indicate that there is a BIOS bug in timeouts at various stages of the POST that cause some initializations to fail and time out when more than 48GB of RAM is used. Officially, EVGA only claim the SR-2 supports up to 48GB of RAM, and it is unlikely they will be fixing this BIOS bug.
Back when I began this project (late 2012), the only hypervisor with notable reports of GPU passthrough success without requiring a lot of manually applied experimental patches was Xen, so this was what I chose for the project. Additionally, my previous tests indicated that the performance overheads of using Xen were among the lowest of all the available hypervisors, so it seemed like a win-win situation.
EVGA SR-2 motherboard uses a pair of NF200 PCIe bridges to multiplex 32 PCIe lanes available on the upstream Intel 5520 PCIe hub into 64 PCIe lanes available for GPUs. NF200 bridges have severe bugs and limitations when it comes to compatibility with VT-d. They bypass IOMMU for DMA transfers, so when the VM tries to access RAM within it’s virtual address space that overlaps the physical address of a PCI BAR (aperture) that belongs to a hardware device, the memory writes will hit the BAR, which will crash the machine (and maybe corrupt your disks, if the BAR being trampled belongs to a disk controller). The solution to this was to write a hvmloader patch that marked all of the IOMEM areas from the host as reserved. This was an ugly bodge that resulted in a fair amount of memory in the domU (what Xen calls guest VMs) becoming unusable, but it worked (and with enough RAM it wasn’t a major problem).
More than likely related to point 1, this motherboard appears to have broken (or non-existent) support for interrupt remapping, which means that any devices passed to a VM have to have dedicated, unshared interrupts. If you pass a device sharing an interrupt to the VM, the VM will most likely crash the entire host. Problems 1 and 2 are very similar in symptoms (host crash), which made them quite difficult to troubleshoot and get to the bottom of because no one change to the configuration made the problem go away. It took some help from the Xen developers and a fair amount of guesswork to figure it all out. The only solution is to move cards around to different slots until all of the hardware you intend to pass through to virtual machines has dedicated interrupts that aren’t shared with other hardware. This can be fiddly, but it is generally achievable – in my final configuration, I am successfully passing two GPUs and three USB controllers to VMs.
Issues 1 and 2 listed above are why I said that claiming the SR-2 supports VT-d was seriously stretching the truth. On a well designed workstation motherboard, the above problems should never have arisen. After all that, and many, many man-days invested in it working around the various bugs mentioned above, I have Xen working on the system, with EL6 (CentOS) dom0, and two domUs, one running XP x64 and one running Windows 7 x64. The hardware passed through on PCIe level is:
Note that unrestricted_guest=1 and pcie_ports=compat are required on the SR-2, but may not be required if you hardware behaves better. If your IOMMU implementation is good and includes ACS functionality, you shouldn’t need unrestricted_guest=1.
pcie_ports=compat is required because without it the SR-2 makes the PCI hotplug driver flap very quickly on one of the PCI devices built into the south bridge chipset, which causes an interrupt flood that makes the machine grind to a halt. (Have I mention enough times yet that the SR-2 is extremely buggy?)
Note the PCI IDs in the xen-pciback module options correspond to the PCI IDs in the Xen domU configuration. You may not need permissive=1 if you have better hardware than I do.
And Another Thing
One thing I feel I have to mention is that I have had extremely bad experience with every SAS card I have tried to use in the SR-2 with virtualization. This includes two different LSI cards, an Adaptec card and a 3ware card. They all work fine in a normal bare metal setup, and cause all kinds of crash inducing problems, some more difficult to debug than others when IOMMU is enabled and VMs are running with PCI devices passed through to them. SATA cards (I tried Silicon Image and Marvell), OTOH, seem to always work just fine, with no problems whatsoever, including when using 1:5 SATA port multipliers. In some cases this is caused by the SAS controller being a native PCI-X chip and using a phantom PCI-X to PCIe bridge. In other cases it seems to be caused by the SAS card’s driver trying to do some interesting DMA accesses that crash the entire host when virtual machines are running with PCI devices passed through to them. In short – avoid using SAS cards and stick with SATA – but then again I find that to be good advice to follow regardless.
This setup has worked without any significant problems for the past two years. But things have changed in that time. There is now a native Linux version of Steam, and many games have native Linux ports. It is time that this long term reliable system is updated accordingly. More on that in the next article.
I have been using my Chromebook Pixel for nearly a year now, so I feel it has been long enough to form a reasonably objective view, which may be useful to others who are considering buying one.
When I bought it, I was looking for a worthy successor to my venerable ThinkPad T60. The ThinkPad had been upgraded as far as it would go, with a 2.33GHz Core 2 Duo, 3GB of RAM, and most importantly, a 2048×1536 screen. It is still quite a usable machine, but the main reasons why I was looking for a replacement were battery life (90 minutes with the extended capacity battery on a good day), and weight (I haven’t weighed it, but when carrying it around for any length of time it feels like it weighs a tonne. All in all, barely livable with for the commute to work.
The Pixel was promising to address all the issues I had with the ThinkPad – it weighs a fraction as much, the battery life is about 6 hours, depending on the load, the other features are no worse, with the screen being a significant improvement on the ThinkPad. Since I use Linux (EL6), I needed to make sure all of the hardware is fully supported, which was the main reason why I didn’t choose a Macbook Pro Retina – the only other contender at the time.
Needless to say, ChromeOS only lasted for long enough to enable developer mode to facilitate installing a proper Linux distribution.
How did this very promising spec on paper work out in reality? Well, my experience is very mixed. The performance is more than sufficient, even for light gaming loads (e.g. Left 4 Dead 2 with maxed out settings at 1280×800, quarter of native resolution). The screen is nothing short of amazing. The touchpad is reliable. The battery life is good. But that is where the good things I can say about it end.
There are two things that let it down quite badly. The keyboard is less than perfect – it lacks a number of keys: PgUp, PgDn, Home, End, Delete, Insert, F11 and F12. While inconvenient, this is reasonably workable around using a custom keyboard map and key combinations using AltGr.
The fundamental thing that makes the Chromebook Pixel nearly unusuable is the amount of heat it produces. Under any load above idle, the aluminium casing gets too hot to touch for any length of time. Under a gaming load, even the plastic keys on the keyboard get so hot they are painful to touch. The CPU itself doesn’t overheat (it tops out at about 85C), but the outer casing gets past 47C within a few minutes of Left4Dead 2.
47C may not sound like a lot, but given the high thermal conductivity of aluminium, 47C is actually very uncomfortable to touch. This problem isn’t unique to the Chromebook, either – I had a similar problem with the Macbook Pro Retina I was using at work previously. Consequently, I can only strongly recommend against getting the Chromebook Pixel.
Due to these issues, I am still using my old ThinkPad more frequently than the Pixel. My commute to work machine is now an ARM based Chromebook (XE303C12), which stays stone cold even under a heavy load, the battery lasts 6-8 hours, and is even lighter than the Pixel. It’s touchpad is quite terrible, but I can live with that in return for it not burning me as soon as I ask it to compile something for me.
All I can say is – beware the marketing hype and sexy looks. A laptop that looks fantastic on paper can easily turn out to be nearly useless due to how hot it gets.