chr.istoph, der Blog

Um VMs zwischen HDD und SSD zu migrieren wäre ein „lvmove“ äquivalent ganz praktisch. Dies kann es aber nicht geben, da der Pfad zum lv dann auch angepasst werden muss. Um meine Master Slave Setup dennoch Live migrieren zu können, habe ich ein neues gleich großes lv erstellt, die Platte ausgehangen und die neue wie folgt eingegangen.

Zunächst habe ich geprüft ob ich Master oder Slave bin (ro:Secondary)

grep -A1 '^11:' /proc/drbd 
11: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
    ns:1176552 nr:236 dw:1176788 dr:233640 al:194 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

Dann habe ich dem DRBD Verbund die Storage aus gehangen:

drbdadm detach drbdvm11
grep -A1 '^11:' /proc/drbd 
11: cs:Connected ro:Secondary/Primary ds:Diskless/UpToDate C r-----
    ns:1176552 nr:272 dw:1176824 dr:233640 al:194 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

Dies DRBD Config Datei editiert und bei der localen node das neue lv auf der neuen vg eingetragen.

vim /etc/drbd.d/drbdvm11.res
disk       /dev/mapper/vg2-drbdvm11;

Danach muss das neue lv von DRBD initialisiert werden:

drbdadm create-md drbdvm11
initializing activity log
NOT initializing bitmap
Writing meta data...
New drbd meta data block successfully created.
success

Anschließend wird alles wieder gestartet und die Synchronisation begibt automatisch.

drbdadm attach drbdvm11
grep -A2 '^11:' /proc/drbd 
11: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r-----
    ns:0 nr:184320 dw:184320 dr:0 al:194 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:7155452
         [>...................] sync'ed:  9.4% (116080/127996)M
grep -A1 '^11:' /proc/drbd 
11: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
    ns:0 nr:7339804 dw:7339804 dr:0 al:194 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

Immer wenn ich meinen Arbeitsplatz verlasse Sperre ich meinen Bildschirm. Vor eingestellt ist ALT + L. Das geht aber einfacher. Unter Systemeinstellungen => Tastatur kann man im Reiter „Tastenkürzel“ die voreingestellten Einstellungen bearbeiten. Unter System => Bildschirm sperren habe ich hier die Pause Taste hinterlegt.

Damit ich aber weiß, wann ich in Pause gegangen bin habe ich mir ein kleine Script geschrieben:

bin/pause

#!/bin/bash
gnome-screensaver-command -l
logger "PAUSE"

Dieses sperrt den Bildschirm und schreibt eine Logzeile ins Syslog:
Jun 6 17:00:00 desktop user: PAUSE

Hierfür habe ich mir unter Systemeinstellungen => Tastatur kann man im Reiter „Tastenkürzel“ ein eigenes Tastenkombination definiert

Im auth.log steht equivalten wann ich mich wieder eingeloggt habe:
Jun 6 18:00:00 desktop compiz: gkr-pam: unlocked login keyring

Ubuntu 16.04 hat eine aktuelle Version von SSH mit an Bord. Hier bei sind die DSA Public Private Key nicht mehr unterstützt und es kommt beim aufrufen von ssh -v zu folgende Debugausgaben bzw. zu Passwort Eingabeaufforderung.

ssh root@server -v
OpenSSH_7.1p2 Ubuntu-2, OpenSSL 1.0.2f  28 Jan 2016
...
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Skipping ssh-dss key .ssh/id_dsa for not in PubkeyAcceptedKeyTypes
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
root@server's password:

Um dies wieder zu erlauben, muss in der /etc/ssh/ssh_config folgender Parameter hinzugefügt werden:

PubkeyAcceptedKeyTypes +ssh-dss

Um die Daten einer Festplatte zu retten auf unter anderem ein LVM Raid1 war, habe ich versucht mit vgchange -ay vg das vg zu starten. Andernfalls waren die LVS nicht unterhalb von /dev/mapper/ nicht aufgeführt.
Nach dem ich aber vgchange -ay vg aufrief war die Festplatte nur noch mit Lesezugriffen beschäftige. Die LVS waren vorhanden aber leisen sich nicht mounten. Somit habe ich den Vorgang mit vgchange -an vg wieder abgebrochen.

Um von hinten am LVM vorbei an die Daten heranzukommen half mir folgende Option mit der ich an die Festplatte bzw. die Position des lvs heran kam:

lvs -a -o +seg_pe_ranges|grep lv
LV   VG Attr       LSize   Convert PE Ranges
WARNING: Device for PV ZfExWH-u4Z9-zuqn-6e8P-ecDe-TYuQ-rBIlQP not found or rejected by a filter.
lv   vg owi-i-s---  40,00g dev/sdc3:38146-48385

In der Datei /etc/lvm/backup/vg fand ich zusätzlich noch folgend Informationen, alle anderen habe ich an dieser stelle ausgelassen:

vg {
        extent_size = 8192              # 4 Megabytes
        physical_volumes {
                pv0 {
                        device = "/dev/sdc3"    # Hint only
                        pe_start = 384          # Ofset

Mit diesen Werten kann man die Position des LVs auf der Festplatte lokalisieren und mit dmsetup einen eigenes device anlegen.

(48385-38146+1)*8192
(Partitionsende – Paritionsanfang + 1) * extent_size = ergibt die gesamt Größe: 83886080

384+38146*8192
pe_start + Paritionsanfang * extent_size begin auf der Parition: 312492416

echo "0 83886080  linear /dev/sdc3 312492416" | dmsetup create -r "lv_ro"

Unter /dev/mepper/lv_ro befindet sich nun das LV das gemountet werden kann.

Wie man an dieser stelle das readonly device mounten kann folgt im nächsten Blog Eintrag.

Heute musst ich einer VM mehr Speicherplatz zuweisen. Da die VM auf einem DRBD Cluster lag bin ich folgendermaßen vorgegangen.

lvs
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
vm1 vg1 -wi-ao--- 67,00g

1. auf beiden VM Host Systemen habe ich das LV vergrößert.

lvresize vg1/vm1 -L 135g

2. Anschließend habe ich auf dem Primary DRBD Konten das DRBD Online vergrößert.

drbdadm resize vm1

cat /proc/drbd
4: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r---a-
ns:86370276 nr:9144 dw:86259976 dr:3566560 al:274 bm:129 lo:2 pe:8 ua:8 ap:1 ep:1 wo:f oos:71188220
[>....................] sync'ed: 0.2% (69516/69628)Mfinish: 0:42:04 speed: 28,192 (28,192) K/sec

Schon während der Synchronisation stand der vergrößerte Platz in der VM zur Verfügung.