LXD with Linux bridges in a VMware environment – the right way

When using LXD containers in a VMware VM, you might want to toss away the default NAT configuration and switch to a more useful setup with bridges attached to the containers.

Unfortunately, this config does not works by default because the vSwitch is blocking all the network traffic coming from other MAC addresses than the ones of the vNICs assigned to the VM.
There is a known workaround that involve configuring the vSwitch in promiscuous mode, but apart from being a security issue, it seems like it won’t works well in some scenarios.

Do we have to abandon the dream of having VMs directly exposed to the external network? No way! The solution is as abandon the bridged mode and use vNIC directly assigned to the container.

Yes, I know it sounds weird, but LXD containers are usually deployed for thick-containers, pet-style scenarios… and, if you are skilled enough, you can always automate vNIC attach/detach and container creation/destruction.
Attaching the network interface to the container is trivial:

lxc config device add $ContainerName eth0 nic nictype=physical parent=$vNIC name=eth0

Have fun!

How to make the Latitude 7490 trackpoint enjoyable in Linux

Everybody knows about the fantastic Thinkpad trackpoint feeling, but what about the Dell one? Well, the hardware is now quite good apart from the nub cap. But the software, as with any trackpoint in Linux, is still lackluster. For example, in Linux you don’t get the middle-button scrolling by default, arguably one of the most useful feature of a trackpoint.

The nub


Those suggestions only works with X11, I don’t know how to tweak this settings with Wayland. Let me know if you find a way to make it works with the new framework.

So, let’s fix it!

In Linux, you can control input devices mainly with two different tools: evdev and libinput.

  • evdev: generic input interface in the kernel, that old guy;
  • libinput: the new shiny stuff that technically sit on top of the evdev interface. It’s the only way to go with Wayland.

While libinput is the default and what should be used today, as every new project it does not support every feature of evdev, E.G. our beloved middle button scrolling; it should come soon some in one of the next releases, but it’s still not there. So, we will revert back to evdev about the trackpoint handling, for now.

In order to do that, we need to create /etc/X11/xorg.conf.d/10-trackpoint.conf . The file name is not important apart for the initial NN- part.

Reboot your machine, and everything should work. I’ve tested this configuration with kernel > 4.12, but I think it should work with older version without issues.

Addition tweaks

Some evdev input options, as far as I know, aren’t directly accessible via the Xorg configuration files, but you can use it via the mighty xinput. For a list of supported devices:

Be careful with devices IDs, they vary wildly between reboots. If you want to script something, always filter the devices by name. For example, we can list the tunable properties of our trackpoint.

One of the few stuff missing is the “Device Accel Constant Deceleration”, AKA the pointer sensitivity. Oh, and the horizontal scrolling. You can adjust them with a pair of commands.

I think that’s all for now, I hope that the Wayland-libinput support will be ready soon… feel free to tell me when this mini-tutorial will became obsolete, and enjoy your Latitude!


Network management with LXD and OpenVSwitch in Ubuntu 18.04

Just some quick notes about my homelab setup of LXD 3.0 with OpenVSwitch (OVS) in Ubuntu 18.04.

Why use OVS in a small homelab environment? Because it’s the most used SDN stack in the world, and you should learn it instead of relying on the traditional Linux bridges, especially if you are into virtualization/containerization or networking stuff.
Ever heard of whitebox switches? They are going to be the dominant platform in the hyperscaler datacenters… and maybe, also in the enterprise market.

A big warning: this is not a “best practices” configuration, the one with overlay switch and tunnel switch as shown in this great article, but I’m still working on that and this simpler one should be ok for some non-enterprise playground.

As of today (today is the first day of Ubuntu 18.04!) Netplan does not directly support OVS, so don’t even try to use it; I hope they will fix it soon, but for now just don’t configure your OVS NIC with Netplan and please fallback to traditional configuration scripts. Or even to manual startup, they are servers and they are meant to be always on anyway… or not? (Thinking of MaaS)

I strongly suggest you to use a machine with multiple NICs, it will make anything a lot easier because you would not be kicked away from the network when adding your only NIC to the OVS bridge.

Just to begin, install OVS with apt install openvswitch-common openvswitch-switch and check the status of ovs-vswitchd.service and  ovsdb-server.service. Don’t forget to enable the ability of kernel to forward packets with the usual echo “net.ipv4.ip_forward = 1” >> /etc/sysctl.conf, followed by sysctl -p /etc/sysctl.conf to reload the config.

After that, do not create any switch in the initial lxd init configuration. Just create an OVS switch in LXD with the command lxc network create ovs-1 bridge.driver=openvswitch. It will automatically be added both to the LXD network profiles and to the OVS configuration, that you can check with ovs-vsctl show. That’s cool! Now it’s time to bind the physical interface to our ovs-1 switch; remember that this will KILL any connection established on the NIC that you choose, so be careful.

After choosing your NIC to bind (list them with the ip link command), type ovs-vsctl add-port ovs-1 eno4; eno4 is my fourth NIC, of course. Now it’s time to apply the network profile we just created to the default profile (but you can choose another one, of course) with lxc network attach-profile ovs-1 default eth0. This way, the first NIC of your LXD container will be a veth port on the OVS switch ovs-1. Start a container in LXD with lxc launch ubuntu:18.04 and check if you got everything right with ovs-ofctl show ovs-1; some veth-stuff should appear. Now, log into your container and play with it’s network configuration: it should appear like it’s on the same L2 switch of the physical NIC eno4.

What you can do now? Easy VLAN tagging, for example: ovs-vsctl set port vethM3WY7X tag=200. Don’t forget to set the switch port physically connected with eno4 as a trunk for the VLAN tag that you choose.
You can also create NIC aliases and bind different OVS switches with different tags to the in the very same NIC, but I have not experimented that yet.

Paranoia, XenServer and libvirt: Full Disk Encryption unlocking from virtual serial TTY

Everybody wants encryption today; encryption of network traffic, mainly.
But what about the encryption of data-at-rest? I mean, what if someone got physical access to your storage?
Of course you can protect specific folders with your tools of choice, but there’s always a chance that some file got saved outside your security fence by a zealous program, or just forgotten by you on the desktop… here comes the Full Disk Encryption (shortly, FDE) to the rescue!

Maybe you are  already using it without being aware of that… if BitLocker on Windows and FileVault on Mac OS X sound familiar, you are on track.

The penguin within

But, what about our beloved Linux machines?
In the Linux world, FDE is mainly achieved through LUKS; this software is capable of encrypting your disks with AESXTS using both passphrases and key files, usually stored in an USB drive and plugged on-demand.

I won’t tell you how to setup LUKS in your machine because you should better refer to the installation manual of your distro.

If you plan to use it with a workstation, you’ll be set already manually inserting the password or the USB drive on every boot.

And my VMs?

But, what if you want to use LUKS in a virtual environment, in a hosted VM?

I won’t talk about acrobatic USB-passthrough, focusing instead on the passphrase method.

Of  course, you can manually type it in your preferred hypervisor VM-console; but because having a very long and random passphrase is of utmost importance, writing a 40 characters long on every server reboot can be extremely tedious and can easily bring to bad habits, like short passphrases, avoiding necessary update-reboot cycles or dumping the LUKS thing at all.

Meeting the serial (killer?)

The best way of input long keys would be having it stored in encrypted keyrings with the possibility to copy-and-paste them into the VM prompt as needed, but the graphical consoles AFAIK don’t support input methods like that, and of course we cannot use SSH&co. because there isn’t any service running in the VM before boot.

There’s another way to access the VM at “physical” level, at least with hypervisors like KVM and XEN: the glorious and vintage serial console!

Maybe you have already heard of it for router configuration; shortly, it was the leading way of talking to an operating system out-of-band before the video output we use today.

Any Linux distribution provide this capability; to enable it in a CentOS 7 guest, you just need to modify your /etc/default/grub to make it looks like this:


GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0,115200"
GRUB_CMDLINE_LINUX="rd.lvm.lv=DONT_CHANGE_IT!/root rd.luks.uuid=DONT_CHANGE_IT! rd.lvm.lv=DONT_CHANGE_IT!/s
wap rhgb"

and rebuild your initrd with grub2-mkconfig -o /boot/grub2/grub.cfg.
Take a snapshot before doing any modification to your grub.cfg, you have been warned!

Now reboot your system and everything should work as before, except for…

Practical unlocking

Yes, now there is an active serial interface that can be used to access your VM from the hypervisor, in a completely textually way.
Really, you can stop typing that super-long random string one-character-at-time right now!

The thing is, how to access it from the virtualization host?

  • If you are using libvirt-virsh framework, you are lucky: just type virsh console VMname and you are set! The exit-escape is CTRL-].
  • If you are on XenServer with XAPI, use the xl console VMname console (same escape). Dump that xe console command, it won’t help you if you are targeting an HVM guest; it is very likely that you are on HVM, you should now if you still are on PV-mode. The xl command solution is undocumented in the XenServer doc, and it’s the actual reason why I wrote this post. 

Oh, XL is also the new default toolstack for XEN management!

Now you should be set and smooth, go and enjoy your very-long and very-random LUKS passphrases!

Devo comprare un computer, mi dai un consiglio?


Mi vengono fatte spesso delle domande da amici e conoscenti riguardo al settore dell’informatica, spesso anche stravaganti.
Dovendo fare una classifica, la richiesta più comune in assoluto è:

Devo comprare un laptop/desktop per lavorare, mi dai un consiglio tu che sei un esperto?

Richiesta quasi sempre seguita da link a volantini pubblicitari che promuovono il modello X in offerta nella catena Y.

Di solito, si tratta di infami accrocchi consumer con un ciclo di vita che non supera i due anni, plastiche di qualità infima, sistema preinstallato pieno di bloatware e garanzia-assistenza striminzite.
Nonché, naturalmente, riparabilità e possibilità di reperire ricambi che si avvicina asintoticamente a zero non appena il modello esce di produzione.

Signora mia, cosa vuole che le dica. Really.

Qualsiasi consiglio io possa dare a riguardo, è spesso preceduto da slogan apodittici come:

Eh, ma non fanno più i computer di una volta, che duravano una vita!

Non è vero, è solo che non li trovi più al centro commerciale in super-offerta… o meglio, lì non li hai MAI trovati.
Una macchina che dura più di un paio d’anni, con costruzione e caratteristiche industry standard, è una macchina professionale.

E le macchine professionali, sono sempre state vendute per altri canali.

È vero, si è verificata una anomalia del mercato (leggi, boom dell’informatica) per la quale per diversi anni la buonissima parte dei computer disponibili sul mercato era costituita da macchine di discreto livello (IBM, Apple, NEC), che non a caso costavano parecchio ed erano pensate per professionisti… anche se poi venivano acquistate dalla famiglia media, sulla spinta della moda e di un marketing che ha cavalcato l’onda.

Un Apple Lisa 2, che nel 1984 costava circa 4000$. Chiedetevi perché nessun Apple moderno si chiami “Lisa”.

Sorpresa: questa categoria di macchine esiste ancora, ma sopratutto è diventata parecchio più conveniente rispetto a qualche anno fa, grazie ai grandi numeri dietro l’industria informatica.

Ma andiamo con ordine…

Linee guida

Vuoi fare un acquisto oculato?

Bene, la prima cosa che devi sapere è che, senza praticamente alcuna eccezione (a parte casi estremamente di nicchia che non ti riguardano, altrimenti non cercheresti un consiglio), ti converrà sempre acquistare il prodotto di un vendor Tier-1, ovvero quelli che hanno il 90% del market share e che progettano/producono ciò che vendono; i vendor Tier-1 sono HP, Dell, Lenovo, Fujitsu, Apple.

Acer, Asus ed MSI, stanno un gradino più in basso.

No, nessun assemblatore (neanche e sopratutto te stesso) può garantirti i livelli di affidabilità, integrazione delle componenti, funzionalità speciali e garanzia offerti da un produttore di primo piano.



Se hai problemi a comprendere come funzioni l’economia di scala, non posso aiutarti.

Dimmi che serie vuoi, e ti dirò cs fai? Cn ki 6 xké nn risp??

I produttori di primo piano, hanno generalmente tre linee di prodotti laptop/desktop:

  • Una serie consumer/economica, dove la variabile più importante è il prezzo d’acquisto;
  • Una serie business, dove si tende a minimizzare il TCO;
  • Una serie orientata alle performance pure.

Naturalmente, per la stragrande maggioranza degli impieghi generici, sarà da preferire la serie che minimizza il TCO.


Ok, se sai già cos’è il TCO hai capito dove voglio andare a parare, puoi saltare a piè pari il paragrafo.

Altrimenti: read on.

Il TCO, Total Cost of Ownership o “costo totale di proprietà” è una misura di quanto costi “in totale” possedere ed utilizzare un bene, includendo tutte le spese (materiali o meno) alle quali si andrà incontro durante il ciclo di vita dell’oggetto.

Ad esempio, a parità degli altri fattori, un computer che ti faccia smadonnare perché devi riavviarlo ogni sei ore , ha un TCO più alto rispetto ad uno che funziona e basta, perché dovrai spendere delle ore/uomo per attendere che riparta.

Un altro fattore determinante nel computo del TCO potrebbe essere l’affidabilità intrinseca dei componenti utilizzati, oppure la possibilità di avere velocemente e in modo gratuito dei ricambi. Oppure ancora, la compatibilità con un software particolare, un centro assistenza in zona, delle caratteristiche tecniche che facciano risparmiare tempo.

Continuo a non capire. Mannaggia.

In soldoni, le macchine business/TCO-oriented solitamente prevedono un investimento iniziale maggiore rispetto alla controparte consumer, ma la spesa complessiva da sostenere durante il ciclo di vita della macchina è minore.
Acquistarle costa di più, ma poi si ripagano.

Insomma, alla lunga convengono. Ecco.


Quali sarebbero queste famigerate macchine business/TCO-oriented? Facciamo un po’ di esempi, soffermandoci ad esempio sui laptop (il settore trainante del mercato):

  • Lenovo ThinkPad;
  • HP Zbook / EliteBook;
  • Dell Latitude / XPS (gli ultimi XPS sono Precision senza GPU discreta).

Cinque tasti fisici, touchpad e TrackPoint (il pallino rosso in alto a destra). Ditemi ancora che voi col portatile usate il mouse esterno.

Cosa hanno in comune queste alternative?

  • Garanzia di almeno 3 anni on-site, spesso espandibile. On-site, vuol dire che aprite un ticket online o telefonicamente, e dopo al più quattro giorni un tecnico recapita e installa fisicamente la parte di ricambio a casa vostra;
  • Espandibilità e possibilità di sostituire storage e RAM senza rendere nulla la garanzia. Disponibilità di ricambi a lungo termine (anche dieci anni);
  • Costruzione, design delle componenti e robustezza anni luce qualsiasi portatile consumer;
  • Parecchie porte fisiche, anche legacy;
  • Buona compatibilità con sistemi Linux;
  • Dispositivi di puntamento avanzati (ah, la TrackPoint!), tastiere resistenti all’acqua, lettori di impronte digitali, possibilità di gestione remota della macchina (vPro) e tante altre features enterprise-grade.

A questo c’è da aggiungere la personalissima considerazione che utilizzare un dispositivo di elevata qualità ripaghi in soddisfazione personale; qualcosa difficile da quantificare economicamente, ma sicuramente percepibile se questo si utilizza su base giornaliera.

L’elefante nella stanza / e il coccodrillo?

Vi starete chiedendo: perché citi la Apple, che ha di fatto una sola linea di prodotti? La Apple è un caso particolare: fino a qualche anno fa vendeva solamente macchine business-grade, affidabili e di solito ben costruite, nonché espandibili/riparabili con una discreta facilità.

Sì, costavano care ed erano superiori alla concorrenza semplicemente perché appartenevano ad un’altra catergoria.
Le ultime incarnazioni (fine 2016) sono dei gingilli consumer ben costruiti, ma che mancano di alcune caratteristiche fondamentali per poter rientrare nella denominazione, ad esempio, di business laptop.

Nomen omen.

So what?

In sintesi: per fare una buona scelta, selezionate sempre macchine business-grade; le aziende sono sempre molto più attente del consumatore al ritorno dell’investimento, quindi difficilmente troverete modelli poco convenienti o di bassa qualità cercando nelle giuste famiglie di prodotti.
Spesso è saggio partire con la minima configurazione che soddisfa i propri requisiti, e aggiungere via via componenti alla bisogna.

Ciò detto, a me piacciono parecchio i ThinkPad. Ma anche l’XPS13 non è affatto male.
Riguardo i desktop, la serie Z di HP è fantastica; per qualunque carico più grosso di quello che possano reggere queste macchine, userei comunque un server.