XEN + SSD + LVM - Wie TRIM aktivieren?

Hallo,

ich arbeite gerade an einem neuen XEN basierten Server und verwende als Systemplatte eine Intel 530 120GB SSD.
Dom0 und aktuell 3 PV DomUs basieren auf Ubuntu 14.04 Server x64 mit XEN 4.4.
Für die flexible Speicherverwaltung wurde die SSD als VolumeGroup (lvm) definiert welche sowohl die rootFS und die swap Partition der dom0 als auch die der domUs beinhaltet. Das Dateisystem ist in allen Fällen ext4.

Nun frage ich mich aber wie man für diese SSD den TRIM support aktiviert?
Jemand eine Idee wie man das mit xen und lvm lösen könnte?

===

Reicht es in dom0 und domUs per cron-job fstrim laufen zu lassen? Braucht es nicht direkten Zugriff zum SATA Controller und was ist mit dem LVM layer dazwischen?

Gruss
tec

Was meinst du denn genau mit "VM Container"?
Die ganze Platte (PV) ist eine VolumeGroup (VG). Darin sind LogicalVolumes (LV) für dom0 und domUs angelegt (jeweils root und swap). DiskImages für die VMs werden nicht verwendet, nur LVs.

Im Ubuntu wiki steht, dass man das online-discard nicht nutzen sollte, also das FS nicht mit dem discard flag mounten. fstrim per cron-job kann dagegen genutzt werden.

Ich bin jetzt aber auf ein weiteres Problem gestoßen. Wenn ich versuche das erste LogicalVolume (root von dom0) zu vergrößern bzw. zu verkleinern geht mit lvreduce/lvextend und anschließendem resize2fs alles gut. Versuche ich das gleiche mit einem der weiteren LogicalVolumes meckert sowohl resize2fs als auch e2fsck dass kein gültiger Superblock gefunden werden konnte. Wieso passiert das und wie kann ich denn sonst die restlichen LVs vergrößern?

===

Hab das Problem mit dem Vergrößern des LV gelöst.
domU runterfahren
LV mit lvextend vergrößern
mit fdisk partitionstabelle des LV löschen und neu anlegen
domU starten und resize2fs ohne Größenangabe ausführen

BTW: Wie hast du bei dir das mit xen-pciback gelöst? Im Ubuntu kernel ist es ja als Modul kompiliert und lässt sich ja nicht über die GRUB_CMDLINE dem kernel übermitteln.
Wenn ich z.B. versuche die beiden usb Controller zu verstecken (hide) klappt das nur in der dom0 mit xl. Das xen-pciback modul mit dem entsprechenden hide parameter zu laden (xen-pciback in der initrd) bringt auch nix, da ehci-pci fest im kernel ist und bereits vorher geladen wird und anscheinend blockiert. Jetzt bin ich dabei den kernel neu zu bauen mit [*]xen-pciback und [M]ehci-pci. Gibt es da evtl. eine andere methode per xl die devices zu verstecken bevor die domUs starten? Wie hast du das gelöst?
Mir ist klar, dass man das auch immer manuell machen kann bevor die domU startet, aber dann kann ich keinen autostart nutzen wenn die Maschine mal runterfahren muss bei Stromausfall und in der USV kein Saft mehr ist.

Gruss
tec

Zitat von fnu

Liegen auf der SSD die virtuellen Disken für VMs oder nicht? Weil 120GB ist recht groß für nur System ...

Ja, auch die VMs sind da drauf. Für die dev domU brauche ich schon 20GB um mal einen kernel bauen zu können und schadet ja auch nicht wenn ein Teil der SSD immer leer bleibt. Außerdem sind die 64GB Modelle auch etwas langsamer, daher 120GB.

Zitat von fnu

Ja, schon, aber da ist bereits ein Job aktiv, der Deine Intel SSD schon erkennen wird. Nur bei SSD Exoten muß man hier eingreifen ...

In der dom0 wird aber nur die root Partition berücksichtigt, also nur ein kleiner Teil der VolumeGroup. In den DomUs funktioniert die Erkennung anscheinend nicht wohl wegen der zusätzlichen Zwischenschicht von XEN.
Daher war meine Frage ob es richtig ist fstrim in jeder VM (dom0/domU) für jedes Volume separat laufen zu lassen. Meine Bedenken habe ich wegen dem recht komplexen Aufbau
[SSD/Controller]->[LVM-Container]->[Backend-XenStore-Frontend]->[FS(ext4)], ob das dann auch so funktioniert wie es soll.
"issue_discards=1" wie in der von dir verlinkten Debian Doku erwähnt ist bei Ubuntu standardmäßig aktiviert.

Zitat von fnu

[Virtualisierung] yaVDR64 0.5 goes Xen Hypervisor - VDR Server als Hypervisor oder in VM inkl. DVB Karten funktioniert nicht?

Hat leider mit den beiden USB Controllern nicht funktioniert mit denen ich es versucht habe. Im dmesg kam die Meldung, dass das device nicht gefunden werden kann und vermutlich bereits genutzt wird. Man hat ja auch gesehen dass das dazugehörige Modul noch vor xen-pciback geladen wurde. Nun habe ich aber den Kernel neu gebaut und pci-back fest und ehci-pci als Modul eingebaut. Jetzt funktioniert diese Methode auch. Blöd nur dass ich jetzt die kernel-updates von Ubuntu nicht mehr mitnnehmen kann, aber egal - ist ja nur ein Home-Server.

Gruss
tec

Ok, das paper ist etwas allgemein und es wird auch Amazon EC2 erwähnt, sonst steht da aber nichts zu xen.
Laut der Xen ML unterstützen bei Xen backend und frontend TRIM bereits seit 2011. Da LVM das wohl auch tut sollte das eigentlich funktionieren.

Wie oben geschrieben ist der "Schalter" aus dem Debian Wiki bei Ubuntu bereits standardmäßig aktiviert.

Ich habe jetzt in einer domU mal "fstrim -v /" laufen lassen und es scheint zu funktionieren.
Heisst für mich jetzt also in den domUs für jedes Volume/Mountpoint einen cron-job erstellen und einmal wöchentlich zeitlich zueinander versetzt fstrim laufen lassen.

Der Vollständigkeit halber falls das Thema jemanden interessiert,

bei Swap kann man keinen Einfluss drauf nehmen wann und ob TRIM ausgeführt wird. Das wird direkt vom Kernel gesteuert.
Was sich aber empfiehlt bei VMs die meist nicht viel Arbeitsspeicher zugewiesen bekommen ist die Nutzung des swap-space auf ein Minimum einzuschränken.
Das geschieht über den Parameter "vm.swappiness" in der "/etc/sysctl.conf" - siehe Ubuntu WIKI.
Der swap-space ist dann nur noch als reiner Sicherheitspuffer da wenn der Arbeitsspeicher mal doch aus welchem Grund auch immer voll werden sollte.

Gruss
tec