Security ist ein stets aktuelles Thema in der IT. Deshalb widmet sich das ADMIN-Magazin 04/2012 speziell Sicherheitsaspekten und gibt Antworten auf die Fragen: ... (mehr)

Festplattenpartitionen

Partitionen einer Festplatte können wie Logical Volumes als Datenträger für virtuelle Maschinen eingesetzt werden. Dazu definieren Sie mit den Libvirt-Werkzeugen eine Festplatte als Speicherpool (Typ »Physical Disk Device« im Virtual Machine Manager) und können anschließend eine Partitionen als Datenträger an eine virtuelle Maschine weitergeben. Dabei müssen Sie natürlich darauf achten, dass Sie nie eine Partition von mehreren Gästen beziehungsweise vom Host-System und einem Gast zugleich ansprechen!

Wirklich empfehlenswert ist diese Vorgehensweise aber nicht: Im Vergleich zu Logical Volumes ergibt sich daraus keine Effizienzsteigerung. Der Grund: Auch beim scheinbar direkten Zugriff auf Festplattenpartitionen führt jede I/O-Operation über KVM. Begraben Sie also die Hoffnung, in einer virtuellen Maschine dieselbe I/O-Performance zu erzielen wie auf dem KVM-Host.

Gleichzeitig geht bei der Administration die Flexibilität von LVM verloren. Außerdem besteht die Gefahr, dass im Gast angelegte Partitionen und LVM-Systeme die Partitions- und LVM-Verwaltung auf dem Hostsystem durcheinanderbringen. Kurzum: Im Regelfall sind Sie gut beraten, Logical Volumes als virtuelle Datenträger zu verwenden, nicht aber Festplattenpartitionen.

Besser keine echten Partitionen

Wenn Sie noch einen Schritt weiter gehen möchten und eine ganze Festplatte oder SSD exklusiv einer virtuellen Maschine zuweisen möchten, stoßen Sie an die Grenzen von KVM. Das KVM-Kommando (nicht aber die Libvirt-Werkzeuge) bietet diese Möglichkeit zwar prinzipiell, die KVM/Qemu-Dokumentation empfiehlt aber dringend, den Zugriff ausschließlich read-only durchzuführen. Der praktische Nutzen ist damit gering. Das zugrunde liegende Problem besteht darin, dass der direkte Zugriff auf eine Festplatte sowohl durch das Host-System als auch durch die virtuelle Maschine Konflikte verursacht. Linux bietet keine Möglichkeit, den Zugriff auf eine Festplatte oder SSD auf einen bestimmten Prozess zu beschränken.

Anstelle des Virtual Machine Managers können Sie die Datenträger auch in der Virtual Shell administrieren. Die »virsh« bietet dazu diverse »pool« - und »vol« -Kommandos. Listing 1 gibt dafür einige Beispiele.»pool-define-as« richtet einen neuen Pool ein. Der erste Parameter gibt den Namen, der zweite den Typ an, zum Beispiel »dir« für ein lokales Verzeichnis für Image-Dateien, »logical« für eine Volume Group (LVM) oder »disk« für eine ganze Festplatte.

Listing 1

virsh-Beispiele

 

Im zweiten Parameter geben Sie den Namen des neuen Speicherpools an. Beachten Sie, dass das »--target« -Verzeichnis bei Pools des Typs »dir« bereits existieren muss.

»pool-start« aktiviert den neuen Pool. »pool-autostart« bewirkt, dass der neue Pool in Zukunft automatisch beim Start des Libvirt-Dämons aktiviert wird.

virsh# pool-define-as new-pool dir --target/data/new-pool
 Pool new-pool definiert.
virsh# pool-start new-pool
 Pool new-pool gestartet
virsh# pool-autostart new-pool
 Pool new-pool marked as autostarted

»vol-create-as« erzeugt in einem Verzeichnis-Pool standardmäßig RAW-Images, wobei der gesamte Speicherplatz sofort alloziert wird. Das können Sie durch die Option »--allocation 0G« verhindern:

virsh# vol-create-as new-pool test1.img 10G --allocation 0G

(In der virsh und in anderen Libvirt-Werkzeugen werden Datenträger als Volumes bezeichnet. Deswegen beginnen alle Kommandos zur Bearbeitung von Datenträgern mit »vol-« .) Tabelle 1 zeigt noch einmal die wichtigsten Kommandos im Überblick.

Tabelle 1

Virsh-Kommandos

Kommando

Funktion

pool-define

Erzeugt einen neuen Speicherpool, dessen Eigenschaften in einer XML-Datei beschrieben sind.

pool-define-as

Erzeugt einen Speicherpool, dessen Eigenschaften in Parametern angegeben werden.

pool-start

Startet (aktiviert) einen Speicherpool.

pool-auto-start

Bewirkt, dass der Speicherpool in Zukunft automatisch gestartet wird.

pool-destroy

Deaktiviert einen Speicherpool. Der Pool kann später wieder mit pool-start aktiviert werden.

pool-delete

Löscht einen Pool, sofern dieser keine Volumes enthält.

pool-list

Listet alle bekannten Speicherpools auf.

pool-info

Liefert detaillierte Informationen über einen Speicherpool.

vol-create

Erzeugt einen neuen virtuellen Datenträger, dessen Eigenschaften in einer XML-Datei beschrieben sind.

vol-create-as

Erzeugt einen neuen Datenträgern, dessen Eigenschaften in Parametern angegeben werden.

vol-delete

Löscht einen Datenträger.

vol-list

Liefert eine Liste aller Datenträger in einem Speicherpool.

vol-inf

Liefert detaillierte Informationen über einen Datenträger.

snapshot-create

Erzeugt einen Snapshot einer QCOW2-Imagedatei, wobei die Snapshot-Parameter in einer XML-Datei beschrieben sind.

snapshot-create-as

Erzeugt einen Snapshot einer QCOW2-Imagedatei, wobei der Snapshot-Name als Parameter angegeben wird.

snapshot-revert

Aktiviert einen zuvor erstellten Snapshot einer QCOW2-Imagedatei.

snapshot-delete

Löscht einen Snapshot einer QCOW2-Imagedatei.

snapshot-list

Listet alle Snapshots einer QCOW2-Imagedatei auf.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2021