☰

DRBD als Blockgerät für XEN VM (Centos 5.3)

tag-icon • tag-icon xen drbd
DRBD als Blockgerät für XEN VM (Centos 5.3)

Ich habe eine DRBD-Ressource zwischen zwei Serverknoten eingerichtet – bei Synchronisierungstests zwischen den beiden funktioniert alles ordnungsgemäß. (Ich möchte einen HA-Cluster mit DRBD, Xen und Heartbeat erstellen.)

Wenn ich jedoch versuche, eine XEN-VM mit Centos als Gastbetriebssystem zu erstellen, gelange ich zwar zum Partitionierungsbildschirm der Installation, aber wenn ich einen Partitionierungstyp auswähle, wird mir auf dem nächsten Bildschirm der folgende Fehler angezeigt:

„Ein Fehler ist aufgetreten – es wurden keine gültigen Geräte zum Erstellen neuer Dateisysteme gefunden. Bitte überprüfen Sie Ihre Hardware auf die Ursache dieses Problems.“

Dies ist der erste Versuch, ein Setup wie dieses zu erstellen, und die Google-Suche hilft nicht viel ...

meine Konfigurationsdateien für DRBD und XEN....

DRBD (nur der relevante Abschnitt)

auf xennode0 { Gerät /dev/drbd0; Datenträger /dev/sda5; Adresse XXXX:7788; intern flexible-meta-disk; }

auf xennode1 { Gerät /dev/drbd0; Datenträger /dev/sda5; Adresse XXXX:7788; intern Meta-Datenträger; }

XEN

kernel = "/boot/xeninstall/vmlinuz" ramdisk = "/boot/xeninstall/initrd.img" extra = "text" name = "VM" maxmem = 3000 memory = 3000 vcpus = 4 on_poweroff = "zerstören" on_reboot = "neu starten" on_crash = "neu starten" vfb = [ ] disk = [ "phy:/dev/drbd0,sda1,w", "tap:aio:/srv/xen/xenswap.img,sda2,w" ] vif = [ "mac=00:16:3e:11:67:ae,bridge=xenbr0" ] root = "/dev/sda1 ro"

Dank im Voraus!

Antwort1

Nun, da ich mir bei der Lösung dieses Problems schon die Haare gerauft habe, möchte ich meine Frage beantworten und jemand anderem die Mühe des Haareraufens ersparen :)

Lösung:

Nach einigem Herumspielen, viel Googeln und Neupartitionieren usw. bin ich zu einem Setup gekommen, das einwandfrei funktioniert.

Es gibt wahrscheinlich einen schnelleren Weg, dies zu tun, aber ich werde diese Antwort nicht übermäßig komplizieren

Ich habe eine Standardinstallation mit folgenden Partitionen durchgeführt (ich habe eine 500-GB-Festplatte):

/boot 100mb 
/swap 4gb 
/     40gb

Der restliche Speicherplatz bleibt unpartitioniert.

Anschließend habe ich mit den folgenden Schritten eine primäre Partition mit dem Namen /dev/sda4 erstellt:

~: fdisk /dev/sda
~: (fdisk shell) p4   (for primary partition # 4)
~: (fdisk shell) t    (hit t and enter to edit the partition type)
~: (fdisk shell) 08e  (Linux LVM)

Starten Sie den Server neu, damit die neuen Partitionen wirksam werden.

Erstellen Sie jetzt logische Datenträger durch:

~: pvcreate /dev/sda4
~: vgcreate xenvg -s 4M /dev/sda4    # (xenvg is the name of my virtual group, you can rename it)
~: lvcreate -L400G -n xenroot xenvg  # (xenroot is going to be my drbd  resource and root partition for my DomU)
~: lvcreate -L4G  -n xenswap xenvg   # (xenswap is my swap file for my DomU)

Nachdem Sie nun die richtige Partitionierung vorgenommen haben, können Sie DRBD mit den folgenden Anweisungen in der Konfigurationsdatei (drbd.conf) installieren.

Ich zeige hier nur die beiden wichtigen Anweisungen an …

{
device  /dev/drbd0;
disk    /dev/xenvg/xenroot;
}

Ihre XEN VM-Konfigurationsdatei muss so aussehen (auch hier nur das Wichtige)

{
disk = [ "drbd:xenvm,xvda,w","phy:xenvg/xenswap,xvdb,w" ]
}

Ich hoffe, das hilft jemandem da draußen ...

Antwort2

Hier sind zwei Punkte wichtig:

  1. Es ist besser, ganze Festplatten anstelle von Partitionen für das Gerät zu verwenden, das die DomU sehen wird
  2. Standard-Gerätenamen innerhalb der DomU verwenden (xvd*)

Über Letzteres bin ich mit dem neusten SLES SP3 Kernel Patch gestolpert: Bis dahin habe ich innerhalb der DomU "sda" als Gerätenamen verwendet.

Jetzt blieb mein paravirtualisiertes DomU während der Anwendung des Kernel-Patches einfach hängen. Ein Strace des Patch-Prozesses zeigte mir, dass etwas versuchte, auf sda zuzugreifen, als wäre es eine physische Festplatte. Nachdem ich sda auf xvda geändert hatte, hatte ich keine Probleme mehr.

Mit CentOS 4 als paravirtualisierte DomU war es auch ziemlich knifflig, "sda" zu verwenden. Ich musste das System davon überzeugen, für dieses Gerät nicht den SCSI-Treiber, sondern stattdessen den Xenblock-Treiber zu verwenden. Im Grunde das gleiche Problem.

verwandte Informationen