Since the miniserver has only a SD-card as internal storage and it’s prone to wear I’m thinking about logging of data outside the miniserver. Loxone offers so called loggers. One possibility is to set the storage location to a syslog target outside the miniserver. so now the data is in /var/log/syslog of alix.

What I need next is a possibility to store the data over a long time and a possibility to display it.

Possibilities I see:

  1. Do everything on my own
  2. influx/grafana
  3. logstash/kibana

Since #1 means work and maintenance and #2 & #3 mean quite a big installation on a small system I’m very open to suggestions of something in between.

When building a house of course the question comes up whether, and immediately after that, how much home automation should be implemented. First step after deciding that I want home automation was the selection of a system. I decided to use loxone. There are reasons:

  1. One of my friends already has some experience with the system
  2. The system is centralized, so in case it has to be replaced it can be done in that central place and no hardware updates are required in the living room. The centralized solution also allows to set up a backup system that provides basic functionality like switching of light and opening/closing of roller blinds.
  3. The company delivers the configuration software with the hardware without additional costs and conditions. If I want to update anything in the future I can do that. If I want to stick with an old version of their software I can stick with that.

The home automation has the goal to be invisible for the user and offer all the functionality that you’re used to in a “normal” home as a base. If you enter a room there shall be a switch that will turn on the light if pressed. Only if you want to you can dim the light by holding the switch or by double clicking.

Also the basic setup should look the same in all the rooms. So I’ve decided for a combination of a normal sized light switch and a 6 pin switch below it.

Details will follow.

The mechanical part of the house already exists:

Since a few weeks I have the new ThinkPad X1 Carbon 6th Generation and
as many people I really like it.

The biggest problem is that suspend does not work as expected.

The issue seems to be that the X1 is using a new suspend technology
called “Windows Modern Standby,” or S0i3, and has removed classic S3
sleep.[1]

Following the instructions in Alexander’s
article

it was possible to get S3 suspend to work as expected and everything was
perfect.

With the latest Firmware update to 0.1.28 (using sudo fwupdmgr update
(thanks a lot to Linux Vendor Firmware Service
(LVFS)
that this works!!!)) I checked if the
patch mentioned in Alexander’s article still applies and it did not.

So I modified the patch to apply again and made it available here:
https://lisas.de/~adrian/X1C6_S3_DSDT_0_1_28.patch

Talking with Christian about it he
mentioned an easier way to include the changed ACPI table into grub. For
my Fedora system this looks like this:

  • cp dsdt.aml /boot/efi/EFI/fedora/
  • echo 'acpi $prefix/dsdt.aml' > /boot/efi/EFI/fedora/custom.cfg

Thanks to Alexander and Christian I can correctly suspend my X1 again.

Update 2018-09-09: Lenovo fixed the BIOS and everything described
above is no longer necessary with version 0.1.30. Also see
https://brauner.github.io/2018/09/08/thinkpad-6en-s3.html

The version of CRIU which is included with
CentOS is updated with every minor CentOS
release (at least at the time of writing this) since 7.2, but once the
minor CentOS release is available CRIU is not updated anymore until the
next minor release. To make it easier to use the latest version of CRIU
on CentOS I am now also rebuilding the latest version in
COPR for CentOS:
https://copr.fedorainfracloud.org/coprs/adrian/criu-el7/.

To enable my CRIU COPR on CentOS following steps are necessary:

  • yum install yum-plugin-copr
  • yum copr enable adrian/criu-el7

And then the latest version of CRIU can be installed using yum install
criu
.

After many years the whole RPM Fusion repository has grown to over
320GB. There have been occasional requests to move the unsupported
releases to an archive, just like Fedora handles its mirror setup, but
until last week this did not happen.

As of now we have moved all unsupported releases (EL-5, Fedora 8 – 25)
to our archive (http://archive.rpmfusion.org/) and clients are now
being redirected to the new archive system. The archive consists of
260GB which means we can reduce the size mirrors need to carry by more
than 75%.

From a first look at the archive logs the amount of data requested by
all clients for the archived releases is only about 30GB per day. Those
30GB are downloaded by over 350000 HTTP requests and over 98% of those
requests are downloading the repository metdata only (repomd.xml,
*filelist*, *primary*, *comps*).

I will be giving two talks about OpenHPC in the next weeks. The first
talk will be at DevConf.cz 2018: OpenHPC
Introduction

The other talk will be at the CentOS Dojo in
Brussels
.

I hope I will be able to demonstrate my two node HPC system based on
Raspberry
Pis

and it definitely will be about OpenHPC’s building blocks:

OpenHPC Building
Blocks

And the results:

OpenHPC Building BlocksOpenHPC Building
BlocksOpenHPC Building
BlocksOpenHPC Building
Blocks

Come to one of my talks and you will able to build your OpenHPC engineer
from the available building blocks.

After having worked on optimizing live container migration based on
runc (pre-copy migration and
post-copy migration)
I tried to optimize container migration in
LXD.

After a few initial discussions with
Christian I started with pre-copy
migration. Container migration in LXD is based on
CRIU, just as in runc and CRIU’s pre-copy
migration support is based on dirty page tracking support of Linux:
SOFT-DIRTY
PTEs
.

As LXD uses LXC for the actual
container checkpointing and restoring I was curious if there was already
pre-copy migration support in LXC. After figuring out the right
command-line parameters it almost worked thanks to the great checkpoint
and restore support implemented by Tycho some time
ago.

Now that I knew that it works in LXC I focused on getting pre-copy
migration support into LXD. LXD supports container live migration using
the move command: lxc move <container> <remote>:<container>
This move command, however, did not use any optimization yet. It
basically did:

  1. Initial sync of the filesystem
  2. Checkpoint container using CRIU
  3. Transfer container checkpoint
  4. Final sync of the filesystem
  5. Restart container on the remote system

The downtime for the container in this scenario is between step 2 and
step
5 and depends on the used memory of the processes inside the container.
The goal of pre-copy migration is to dump the memory of the container
and transfer it to the remote destination while the container keeps on
running and doing a final dump with only the memory pages that changed
since the last pre-dump (more about process migration optimization
theories
).

Back to LXD: At the end of the day I had a very rough (and very
hardcoded) first pre-copy migration implementation ready and I kept
working on it until it was ready to be submitted upstream. The pull
request
has already been merged
upstream and now LXD supports pre-copy migration.

As not all architecture/kernel/criu combinations support pre-copy
migration it has to be turned on manually right now, but we already
discussed adding pre-copy support detection to LXC. To tell LXD to use
pre-copy migration, the parameter ‘migration.incremental.memory’ needs
to be set to ‘true’. Once that is done and if LXD is instructed to
migrate a container the following will happen:

  • Initial sync of the filesystem
  • Start pre-copy checkpointing loop using CRIU
    • Check if maximum number pre-copy iterations has been reached
    • Check if threshold of unchanged memory pages has been reached
    • Transfer container checkpoint
    • Continue pre-copy checkpointing loop if neither of those
      conditions is true
  • Final container delta checkpoint using CRIU
  • Transfer final delta checkpoint
  • Final sync of the filesystem
  • Restart container on the remote system

So instead of doing a single checkpoint and transferring it, there are
now multiple pre-copy checkpoints and the container keeps on running
during those transfers. The container is only suspended during the last
delta checkpoint and the transfer of the last delta checkpoint. In many
cases this reduces the container downtime during migration, but there is
the possibility that pre-copy migration also increases the container
downtime during migration. This depends (as always) on the workload.

To control how many pre-copy iterations LXD does there are two
additional variables:

  1. migration.incremental.memory.iterations (defaults to 10)
  2. migration.incremental.memory.goal (defaults to 70%)

The first variable (iterations) is used to tell LXD how many pre-copy
iterations it should do before doing the final dump and the second
variable (goal) is used to tell LXD the percentage of pre-copied
memory pages that should not change between pre-copy iterations before
doing the final dump.

So LXD, in the default configuration, does either 10 pre-copy iterations
before doing the final migration or the final migration is triggered
when at least 70% of the memory pages have been transferred by the last
pre-copy iteration.

Now that this pull request is merged and if pre-copy migration is
enabled a lxc move <container> <remote>:<container> should live
migrate the container with a reduced downtime.

I want to thank Christian for the collaboration on getting CRIU’s
pre-copy support into LXD, Tycho for his work preparing LXC and LXD to
support migration so nicely and the developers of
p.haul for the ideas how
to implement pre-copy container migration. Next step: lazy
migration
.