Tag: kernel

VMware Workstation su Linux host: come ricompilare i moduli da riga di comando

Alberto Scotti

Primo post del 2016!

Perdonate la lunga assenza, ma sono stato lontano dal blog causa lavoro | mancanza di ispirazione a scrivere | vita privata.
Riprendo, spero in maniera più assidua, con un piccolo appunto: come ricompilare, su VMware Workstation in un host Linux, i moduli (vmnet, vmbridge, vmmon) VMware da riga di comando, cosa utile quando viene aggiornato il kernel.

Collegandosi come root è sufficiente lanciare:

root@altair:/home/albertoscotti# vmware-modconfig --install-all --console

Al termine della breve compilazione, se tutto è andato a buon fine, i servizi di VMware verranno avviati senza errori.

 

CentOS 7: come installare VMware Workstation 10 e risolvere il problema di compilazione di “vmnet”

Alberto Scotti

E’ possibile installare VMware Workstation 10 su CentOS 7, pur non essendo al momento una distribuzione supportata ufficialmente, a patto di installare un paio di package extra e smanettare un po’ con i sorgenti del modulo vmnet di VMware.

In particolare, anche se l’installazione di VMware viene completata correttamente, non è possibile avviare il programma poiché il modulo kernel “vmnet”, necessario per il funzionamento della virtual network, non viene compilato a causa di una incompatibilità tra i sorgenti di vmnet ed i sorgenti del kernel.

Per installare WMware Workstation su CentOS 7 dobbiamo (come root):

  1. aggiornare il sistema:
    yum update kernel
  2. riavviare
  3. installare i sorgenti del kernel e l’ambiente base per compilare:
    yum install gcc kernel-headers kernel-devel
  4. installare VMware

Completata l’installazione, avviando VMware partirà il task di compilazione del modulo vmnet da inserire nel kernel, ma la compilazione fallirà e verrà creato un log con i dettagli dell’errore.

A questo punto viene il bello: bisognerà editare un file dei sorgenti di vmnet per correggere un paio di errori:

  1. andare in:
    /usr/lib/vmware/modules/source
  2. scompattare l’archivio dei sorgenti di vmnet:
    tar -xvf vmnet.tar
  3. portarsi nella directory estratta:
    cd vmnet-only
  4. editare il file filter.c:
    vi filter.c
  5. alle righe 206 e 259 modificare la stringa:
    #if LINUX_VERSION_CODE < KERNEL_VERSION(3, 13, 0)
    in
    #if LINUX_VERSION_CODE < KERNEL_VERSION(3, 0, 0)
  6. tornare in:
    cd /usr/lib/vmware/modules/source
  7. aggiornare l’archivio vmnet.tar con il file modificato:
    tar -uvf vmnet.tar vmnet-only

Con questa semplice modifica ora sarà possibile avviare VMware Workstation e far compilare correttamente vmnet.

 

Linux: come individuare la frequenza del kernel timer degli interrupt

Alberto Scotti

Per individuare nel kernel in esecuzione la frequenza del timer degli interrupt va usato il comando:

albertoscotti@scorpius:~$ grep HZ /boot/config-`uname -r`
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
CONFIG_RCU_FAST_NO_HZ=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_MACHZ_WDT=m

I valori che ci interessano sono quelli di CONFIG_HZ= e CONFIG_HZ_valore=, che nel mio caso sono settati a 1000.
Qualora sia presente la voce CONFIG_NO_HZ allora siamo in presenza di un kernel tickless dove la generazione degli interrupt avviene on-demand e non ad intervalli predefiniti di tempo.
Nel mio caso, essendo definito anche il valore CONFIG_NO_HZ_IDLE, ho un kernel in cui la generazione degli interrupt è mista: on-demand se il processore è idle e ogni 1000Hz se il processore è sotto carico.

 

Linux e XFS: come controllare la frammentazione del filesystem e deframmentarlo

Alberto Scotti

Per gestire le partizioni XFS in Linux è necessario il pacchetto xfsprogs, mentre il pacchetto opzionale xfsdump contiene alcune preziose utility per controllare la frammentazione del filesystem e dei file.

Per verificare lo stato di frammentazione di un filesystem XFS lanciare il comando xfs_db e verificare il valore fragmentation factor:

# xfs_db -c frag -r mount_point
actual 288787, ideal 286616, fragmentation factor 0,75%

Nel mio caso il valore è molto basso, non è quindi necessario riorganizzare il filesystem.

E’ possibile controllare la frammentazione anche solo di singoli file, tramite il comando xfs_db:

# xfs_bmap -v nome_file_frammentato
nome_file_frammentato:
 EXT: FILE-OFFSET          BLOCK-RANGE          AG AG-OFFSET                 TOTAL
   0: [0..524159]:         499404728..499928887  1 (134240184..134764343)   524160
   1: [524160..2097023]:   504064368..505637231  1 (138899824..140472687)  1572864
   2: [2097024..27320671]: 542998144..568221791  1 (177833600..203057247) 25223648

In questo caso nome_file_frammentato ha 3 frammenti (extents).

Nel caso in cui invece il fragmentation factor sia consistente, io considero consistenti valori >= 20%, per deframmentare un filesystem XFS lanciare il comando:

# xfs_fsr -v -t 600 mount_point

oppure per deframmentare un singolo file:

# xfs_fsr -v nome_file_frammentato

 

Linux: come abilitare TRIM per ext4 sui dischi SSD

Alberto Scotti 1 Comment

In Linux il supporto automatico al comando TRIM è stato introdotto dal kernel 2.6.33 per il filesystem ext4, tuttavia nella stragrande maggioranza dei casi non è attivo di default: prima di eseguire la procedura è quindi bene verificare di avere un kernel recente (anche un uname -a dovrebbe essere sufficiente).

Per attivare TRIM è necessario editare il file /etc/fstab per fare sì che al riavvio il filesystem venga montato con l’opzione discard:

/dev/sda2  /  ext4  noatime,discard  0 1

Ubuntu Server, rimuovere i vecchi kernel dal sistema

Alberto Scotti

Sei un sysadmin pigro e accidioso? La / del tuo server linux Ubuntu è oberata di immagini obsolete del kernel che ti portano via prezioso spazio disco, ma non sai come fare a cancellarle?
Ecco un piccolo consiglio per spazzolare via tutto quello che non serve più: ti aiuterà e farà fare bella figura con i tuoi utenti. 🙂

Per prima cosa, diventa root:
sudo -s -H

Ora, fai la lista di quanti e quali sono i kernel installati nel sistema lanciando il comando:
dpkg -l | grep linux-image

Verrà restituita, a seconda di quanti kernel sono stati rilasciati, una lista simile a questa:

ii linux-image-2.6.31-15-generic-pae 2.6.31-15.50 Linux kernel image for version 2.6.31 on x86
ii linux-image-2.6.31-16-generic-pae 2.6.31-16.53 Linux kernel image for version 2.6.31 on x86
ii linux-image-2.6.31-17-generic-pae 2.6.31-17.54 Linux kernel image for version 2.6.31 on x86
ii linux-image-2.6.31-19-generic-pae 2.6.31-19.56 Linux kernel image for version 2.6.31 on x86
ii linux-image-2.6.31-20-generic-pae 2.6.31-20.57 Linux kernel image for version 2.6.31 on x86

Nel mio caso, sul server sono installati 5 kernel, di cui i primi 4, come facilmente intuibile dal numero di build, sono sicuramente obsoleti, bacati e probabilmente anche vulnerabili.

Parti dal primo kernel, il più vecchio, e rimuovilo lanciando il comando:
apt-get remove linux-image-2.6.31-15-generic-pae

Completata la rimozione, procedi con il successivo fino a quando non avrai nel sistema solo il kernel più recente.
ATTENZIONE!!! Ricordati che per far funzionare un server serve almeno UN kernel… 😀

Per finire, esegui il seguente comando per rimuovere automaticamente eventuali pacchetti non più necessari associati ai kernel rimossi:
apt-get autoremove

Et voilà il gioco è fatto!
( facile, eh? )