OK, I'm not the first to talk about Windows and ACPI shutdown: as a simple Google Search shows, many sites / blogs have talked about it in the past years. Why it is such a big deal, when we can simply press the “shutdown now” button that Windows show us? Because with the rise of virtual machines it become quite important to be able to automatically execute a clean and fast shutdown of all running guests, without the need to manually login in each one. Theoretically, all you need to do is to issue an “ACPI shutdown” command to the running guests and voilà – it should respond to the ACPI event initiating a proper OS shutdown. However, things rarely are so simple: by default, the various Windows versions respond to ACPI events with different behavior – sometime doing nothing.
This is more or less a self-note, but I think it can be useful to others also.
If you have any DELL server running Linux, chances are you installed the Open Manage Server Administrator tool - OMSA in short. This tool traditionally came via the DELL Linux Repository but, from version 8.x onward, it had to be fetched from the new DELL System Update repository.
So far, so good - if you need a recent version of the OMSA tool, simply use the new repository. Problem is that its latest release seems not so well tested on DELL's Gen11 servers (which, by the way, should be fully supported). For example, while the 16.02.00 release (February 2016) worked fine, the latest 16.03.00 update (March 2016) was completely broken on my PowerEdge R615: the dsm service segfaulted on startup, with in turn make the other utilities (eg: omreport and omcontrol) completely useless. Maybe updating hardware firmware will solve that, but a segfault is never a good thing to see.
Virtual machines storage performance is a hot topic – after all, one of the main problem when virtualizing many OS instances is to correctly size the I/O subsystem, both in term of space and speed.
Of course performance is not the only thing to consider: another big role is played by flexibility and ease to use/configure. So the perfect storage subsystem is the right compromise between performance, flexibility and ease to use.
In a somewhat ironic manner, of the three requisites written above, performance is the most difficult thing to measure, as“I/O speed” is an ephemeral concept. It is impossible to speak about I/O performance without taking into account three main parameters: I/O block size, I/O per seconds (IOPS) and queue depth (the number of outstanding, concurrent block requests). This represent the first problem to correctly size your disk subsystem: you had to guess about the expected access pattern, and you better guess right.
You probably know what LVM is: is Linux's Logical Volume Manager. Its role is to give you a flexible partition scheme for your ever-increasing disk space: while standard partition (MBR or GTP style) are semi-static entries (they can be quite tricky to resize), expanding a LVM based partition is a much nicer experience.
However, while LVM's dynamic nature is a much appreciated feature, in complex situations you can find normal LVM volumes not flexible enough.
NOTE: these information were originally provided in a post I wrote on the Joomla forum
Many CentOS and Joomla users had a bad surprise lately: while Joomla 3.2 happily run on CentOS provided PHP packages (5.3.3), the 3.3 update strongly refuse to run on anything that PHP 5.3.10, citing security issues as the main reason. In my opinion, this is not a wise move - after all, the long-term distribution all apply custom patches and backports to their PHP version and, in this specific case, CentOS packages provide absolutely comparable security to the target 5.3.10 PHP version.
Anyway, we can do very little to change this situation: Joomla developer stated that the will not support older PHP version. So, how can we use Joomla on our beloved CentOS 6.x installations? While custom-patching Joomla's version-check functions can be tempting, this is not the best thing to do: any custom patching increase the risk of future problems, especially when updating your Joomla installation. On the other side, simply using a more up-to-date repository featuring PHP 5.4+ can not be practical: maybe you have other sites on hosted on your server, and (correctly) you don't want to introduce any possible problems for this sites, or you simply want to stick with default repositories.
Fortunately, the solution exists: say hello to "Software collections" or SCL in short.
- Linux compressors comparison on CentOS 6.5 x86-64: lzo vs lz4 vs gzip vs bzip2 vs lzma
- KVM scalability and consolidation ratio: cache none vs cache writeback
- KVM VirtIO paravirtualized drivers: why they matter
- A look at how NCQ, software queue and I/O schedulers impact disk performance
- EXT3 vs EXT4 vs XFS vs BTRFS filesystem comparison on Fedora 18