PCI passthrough is the process of attaching a PCI-E device directly to a VM; CPU support (namely VT-D for Intel and AMD-V for AMD) and motherboard support (IOMMU) are required for PCI passthrough to work properly. Hardware configuration used: AMD Ryzen 1700x Gigabyte X370 K7 Nvidia Geforce GTX260 32 GiB of RAM and a few HDDs Fedora 29 as host OS The system only has a single graphic card because it is normally used as headless compute server for which a GPU is not really required; the graphic card is also very very old Nvidia Geforce GTX260 with a standard non UEFI BIOS. If using an UEFI enabled graphic card it is probably required to install the OS in UEFI mode using a virtual UEFI BIOS. This guide assumes you already have a working Windows virtual machine and are familiar with libvirt. First of all, edit GRUB to enable IOMMU and blacklist nouveau kernel module so that the graphic card is not picked up anymore by the host: …

The idea here is to be able to power on and unlock a remote Full Disk Encrypted (FDE from now on) server. I will leave the how “remotely power on” to the reader to figure out and focus on the other part. The easiest way to accomplish it is by using a program called: dracut-crypt-ssh. $ yum install dropbear dracut dracut-network openssh libblkid-devel gcc $ git clone https://github.com/dracut-crypt-ssh/dracut-crypt-ssh.git $ cd dracut-crypt-ssh $ ./configure $ make $ sudo make install After compiling and installing dracut-crypt-ssh configure grub to instruct dracut to add networking to initramfs: …

QCOW2 disk images can be easily grown using libvirt command line utils. Unfortunately it isn’t possible to grow QCOW2 images in-place or online. First of all, power off the virtual machine, grow the file and make a copy of it: $ qemu-img resize image.qcow2 +200G $ cp image.qcow2 image-new.qcow2 Identify the specific partion you intend to grow: $ virt-filesystems -a image.qcow2 -l Name Type VFS Label Size Parent /dev/sda1 filesystem ext4 - 536870912 - /dev/sda3 filesystem xfs - 45885612000 - Expand the actual partition: …

Yesterday I was reading phoronix 0 and phoronix 1 articles on STIBP mitigation impact on CPU performance, since I run a pretty old laptop equiped with a Sandy Bridge CPU I figured that I should do my own tests to see how bad things really are or aren’t. CPU: Intel Core i3-2310M - 2 cores / 4 threads Motherboard: Lenovo Thinkpad RAM: 2x4 GB DDR3 @1333 MHz HDD: Plextor M5pro OS: Fedora 29 x86_64 with stock kernels My benchmark of choice is compiling the Linux kernel (version 4.19.2). What I do is download the kernel version to /dev/shm ramdisk and compile it using the defconfig configuration while checking how many seconds it takes to complete the task. …

In the last couple of months Xorg has been crashing more or less on a daily basis. What happens is that while you are there browsing the internet, or certain times even doing literally nothing, Xorg crashes and after a second of black screen the user is sent back to the login page. Hardware configuration of my machine is: CPU: AMD Ryzen 7 1700x Motherboard: Gigabyte X370 K7 - BIOS F23d RAM: 2x16 GB DDR4 HDD: Samsung 850 Pro GPU: Nvidia GTX260 Monitor 0: Dell U2412M connected via DVI-D Monitor 1: Dell U2412M connected via HDMI-DVI cable OS: Fedora 28 and Fedora 29 x86_64 GPU driver: nouveau, various versions others: varius versions of Linux, Xorg, mesa, etc I don’t think having two monitors is the culprit nor using a very old Nvidia graphic card is because a friend of mine runs a completely different system (AMD Radeon RX480, single monitor connected using Display Port) and still suffer from the very same problem. Upgrading from Fedora 28 to Fedora 29 nor installing updates in a timely manner solved the issue for me; searching on the interwebz also did not yeld any result. After yet another crash, today I finally decided it was time to investigate the issue. First thing I noticed is that Xorg log file is literally spammed with the following error: …

Today I red an article that was comparing Fedora 29 and FreeBSD 11.2 network performance in a KVM/Qemu environment. Since I use KVM/Qemu and also Fedora and Freebsd I powered on a couple of vm and did my own tests. Results are quite interesting, I expected FreeBSD to be faster but it turns out Fedora 29 actually is. Host system configuration: CPU: Ryzen 7 1700x @4 GHz Motherboard: Gigabyte X370 K7 - BIOS F23d RAM: 2x16 GB DDR4 @3133 MHz CAS 16 HDD: Some Samsung SSD Operating systems Host: Fedora 29 x86_64 Fedora VM0: Fedora 29 X86_64 Fedora VM1: Fedora 29 X86_64 FreeBSD VM0: FreeBSD 11.2 x86_64 FreeBSD VM1: FreeBSD 11.2 x86_64 Virtualization techonology: Qemu+KVM Linux kernel version: 4.18.17-300.fc29.x86_64 What I did was setup 2 hidentical Fedora 29 virtual machines and 2 hidentical FreeBSD 11.2 virtual machines, every one of them had iperf3 installed on it. …

XMPP over TLS (formerly XEP-0368) is a clever mechanism that allows users to connect to a XMPP server from networks that restrict outgoing traffic only to specific ports; this block is circumvent by routing XMPP traffic via port TCP 443. If the server hosts only a XMPP server setting up XMPP over TLS is pretty easy, just instruct the server to listen on port 443. If the server also runs a webserver which is listening on port 443 things are a bit more complicated; luckily Nginx provides a way to manage XMPP traffic and redirect it to the XMPP server. …

Guess it is time to write my first post using Hugo. Yesterday I downloaded a torrent consisting of 2 years worth of 4chan posts, the plan was to mess with it and use the data to train a chatbot. Dealing with big datasets is always fun because even the easiest tasks tend to get complicated, for example extracting the data from a ~3 GB tar.gz compressed archive was a challenge by itself. Running “tar -xzvf archive.tar.gz” resulted in TAR/the Linux kernel eating the whole available memory to use it as cache, when that was down to ~200 MB of free RAM my workstation started lagging so hard that even Xorg was freezing for a couple of seconds every 20 or so seconds. To solve the issue what I did was running the following commands: …