Keine Libvirt Unterstützung für Festplatten in Linbo

Clientpflege linbo
1

Hallo Liste!

Meine Vorlage-Clients sind alle mit KVM virtualisiert. Funktioniert gut, nur das Schreiben ist sehr langsam. Der Grund: Linbo findet keine virtio-Blockdevices (also etwa /dev/vda). Sata hingegen geht.

Vielleicht fehlt das passende Kernelmodul. Eigenartig nur: Im Linbo-Changelog werden virtio-Treiber aufgeführt:

linuxmuster-linbo (1.1.12-1) unstable; urgency=low
[...]
- linbo_cmd: added /dev/vda kvm virtio block device support

Wir setzen linbo 2.3.31 ein.
Setzt jemand linbo mit virtio disks ein?
Gruß
Frithjof

2

Hallo Frithjof,

ja, hier habe ich einen virtualisierten Client und verwende VirtIO als Festplattenbus. Meine Linbo-Version ist ebenfalls 2.3.31 und die Festplatte liegt auf /dev/vda
Ich frage mich nur, wie ich dir weiterhelfen kann? Es ist schon länger her, dass ich diesen Client eingerichtet habe. Ich kann dir anbieten, gezielt Einstellungen nachzuschauen.
VG
Christian

3

Hallo Frithjof,

Ja, ich auch, seit Jahren.
Hm. Gute Frage: Maschine runterfahren. Die XML-Datei mit meiner Vergleichen?

Bsp: der Anfang aus /etc/libvirt/qemu/linboclient01.xml, guck mal ob es der “type” “hvm” ist, der bei dir anders ist. Hab da so eine Erinnerung…

<domain type='kvm'>
  <name>linboclient01</name>
  <uuid>80d2d1c1-5770-3420-9e1d-fc7bcd61ab1f</uuid>
  <memory>1048576</memory>
  <currentMemory>1048576</currentMemory>
  <vcpu>1</vcpu>
  <os>
    <type arch='x86_64' machine='pc-1.0'>hvm</type>
    <bootmenu enable='yes'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/bin/kvm</emulator>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw' cache='none'/>
      <target dev='sda' bus='sata'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' unit='0'/>
    </disk>
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw' cache='none' io='native'/>
      <source dev='/dev/vghost/linboclient01'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </disk>

VG, tobias

4

Hallo!

bei mir geht das auch, ich musste eben nur in der start.conf auch auf /dev/vdaX umstellen und auch die fstab per postsync anpassen.
Da mir das dann aber für Vorlagen zu ätzend war, habe ich es auf sda gelassen, damit ich beim überspielen auf “echte” Clients nix ändern muss.

LG
Max

5

Natürlich die Start.conf! Daran hab ich nicht gedacht. s/sda/vda und schon gehts.
Danke für den Hinweis!
Es ist natürlich unschön, dass ich jetzt muss zwei start.conf-Dateien synchron halten muss. Hat jemand eine Idee, wie das besser gehen könnte?

6

Hi :slight_smile:
Quick&Dirty könnte man einen Cronjob einrichten, der regelnmäßig
sed -e "s/sda/vda/g“ start.conf.1 > start.conf.2
aufruft.
Wenn man das vor dem Unterricht laufen lässt und vielleicht abends nochmal, dann ist immerhin ausgeschlossen, dass man es vergisst. Eine Falle lauert allerdings dann… wenn man start.conf.2 von Hand editiert, macht der Cronjob diese Änderungen rückgängig…

LG Jesko

7

Hallo,

ich verstehe nicht, wo das Problem ist.
Man macht eine neue Gruppe
-v
So hat man dann
start.conf.
und
start.conf.-v

in “-v” ersetzt man sda durch vda, fertig.

Oder verändert ihr die start.conf der Gruppe öfters?

Und wegen der fstab:
die würde ich beide auf den server legen.
Die mit sda nach common und die mit vda nach
Den REst macht der postsync.
Dann ist nämlich egal, was tatsächlich im Image steht: die fstab wird
immer ersetzt: sowohl beim v-rechner als auch bei allen anderen.

LG

Holger

8 
# TAG_convert_to kvm_ group: sed "s/sda/vda/g;s/Group = xenialmate/Group = kvm_xenialmate/;/.*TAG_convert_to/d" start.conf.xenialmate > start.conf.kvm_xenialmate

Ich ersetze bei mir noch die Zeile mit "Group = " (und lösche danach die Zeile mit dem TAG).
VG, Tobias

9

Ja, das würde wirklich gehen. Man könnte auch incrond oder ähnliches benutzen. Es tut aber genau das was ich vermeiden möchte: Noch ein Layer an Komplexität. Ich glaube, ich werde Holgers Variante benutzen.

Das geht jetzt mit den Labels auch ohne Postsync ziemlich gut.

Beide Vorschläge machen mir meine Bauchschmerzen noch einmal deutlich: Ich beobachte fasziniert einen Linuxadmin, der sich bei uns an der Schule sich in Linuxmuster einarbeitet. Da kommen häufig Fragen wie: “Warum ist meine /etc/security/pam_mount_conf.xml wieder zurückgestellt?” Oder: “Kannst du mir noch einmal genau erklären, wie die Grub-Konfiguration auf den Clientes entsteht und wie sie dahin kommt?”
Das hat mir deutlich gemacht, dass die Methode “Noch-ein-Script-drauf” nicht unbedingt hilfreich ist.

Bei meinem Fall wäre vielleicht eine Möglichkeit die Festplatten unabhängig von ihrer Bezeichnung im Kernel anzusprechen hilfreich: etwa “Drive1” oder “BiggestDrive”. Sollten im Client mehr als eine Platte stecken, ist es eh nicht gegeben, dass Kernel und Clientübergreifend die Platten immer gleich enummeriert sind.

Viele Grüße
Frithjof