[Eisfair_dev] [e1] eiskernel 2.5.8 (Status 'testing') verfügbar - 3.2er Kernel für eisfair-1

[Helmut Backhaus]

Hallo Thomas,
danke schon mal für Deine Ausführungen!

Ich habe das ganze mal nach Geschnatter verschoben, ich hoffe, dass das 
recht ist. ;-)

xpost & fup gesetzt


Am 18.06.2015 um 15:44 schrieb Thomas Zweifel:
> Hallo Helmut
>
[..]
>>>>> Für eine PVM wird im Prinzip weder grub noch lilo benötigt, den kernel
>>>>> und die initrd gibt man entweder direkt der Konfigurationsdatei der VM
>>>>> mit (muss man zuerst auf den Host kopieren), oder wenn vorhanden kann
>>>>> man pygrub als bootlader verwenden.
>>>>> Pygrub sucht sich anhand der menu.lst (grub.conf) den eingetragenen
>>>>> kernel und die initrd aus der partitionierten "Harddisk" und startet
>>>>> diesen.
>>>>
>>>> Wenn mich nicht alles täuscht, sieht ein virtueller eisfair Deine
>>>> grub.conf auf dem Host aber überhaupt nicht. Das Kernel-Update läuft ja
>>>> in dem virtuellen eisfair.
>>>
>>> Nein, das ist eine "Normale" Festplatte wie sie der E1-Installer damals
>>> auch "gesehen" hat.
>>
>> Wie hast Du das gemacht?
>> Ein Image von der HD gemacht und dann auf das LVM entpackt?
>
> Bei CentOS geht das direkte installieren über eine GUI.

OK, ich gehe davon aus das Du mit XenServer unter CentOS mit aktivem XCP 
und Open xen Manager arbeitest, richtrig?

>
> Ähnlich wie bei der VirtualBox GUI (unter Windows), weist du Speicher,
> CPU, HDD, CDROM.... zu, danach wird von der CD gebootet und der
> Installer sieht und nutzt die Ressourcen der HVM zum normalen
> installieren des Gast-Systems.

Das war auch ein Lösungsansatz den ich versucht habe. Ich habe einfach 
einen Eis in VirtualBox installiert und dann den "Virt Kernel" 
eingespielt. Daraus habe ich mir dann mit dem Image Tool aus VirtualBox 
ein Image erstellt und versucht dieses Image in meinen Xen von einem LVM 
zu starten, hier die "cfg" dazu:

bootloader = '/usr/lib/xen-4.1/bin/pygrub'
memory      = '512'
boot	    = 'dc'
root        = '/dev/sda ro'

extra = "ro quiet xencons=tty1"
disk        = [
                   'phy:/dev/vg1/eis1-7,sda,w',
name        = 'eis1-7'
vif         = [ 'ip=192.168.100.249, bridge=xenbr0, vifname=vif-eis1-7, 
mac=00:16:3E:79:AE:7E' ]
on_poweroff = 'destroy'
on_reboot   = 'destroy'
on_crash    = 'destroy'

Der Start bringt dann folgendes Ergebnis:

-- PYGRUB Anzeige --
Started domain eis1-7 (id=3)
                             i8042: No controller found
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
Loading Input/USB/SCSI/SATA/RAID drivers ...
Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(0,0)
Pid: 1, comm: swapper/0 Not tainted 3.2.54-eisfair-1-VIRT #1
Call Trace:
  [<c13345ab>] ? printk+0xf/0x11
  [<c13344a4>] panic+0x50/0x148
  [<c1474ab9>] mount_block_root+0x1e3/0x1f7
  [<c10a5267>] ? sys_mknod+0x13/0x15
  [<c1474c14>] mount_root+0x8e/0x96
  [<c14755c4>] initrd_load+0x1fd/0x2c9
  [<c1474716>] ? start_kernel+0x2f5/0x2f5
  [<c1474cd9>] prepare_namespace+0xbd/0x16c
  [<c1474816>] kernel_init+0x100/0x10c
  [<c13373b6>] kernel_thread_helper+0x6/0x10
root at deb64-xen:/etc/xen#

>
> Ein Klon einer HDD geht natürlich auch, wenn das OS die Platte erkennt
> und bootet. (also passende Treiber hat!)
>
>
>>> eis3 # fdisk -l /dev/xvda
>>> Disk /dev/xvda: 4294 MB, 4294967296 bytes, 8388608 sectors
>>> Units = sectors of 1 * 512 = 512 bytes
>>> Sector size (logical/physical): 512 bytes / 512 bytes
>>> I/O size (minimum/optimal): 512 bytes / 512 bytes
>>> Disk label type: dos
>>> Disk identifier: 0x239e30c8
>>>       Device Boot   Start       End    Blocks   Id  System
>>> /dev/xvda1   *       63     96255     48096+  83  Linux
>>> /dev/xvda2        98304    370687    136192   82  Linux swap / Solaris
>>> /dev/xvda3       370688   8388607   4008960   83  Linux
>>
>> Wie bekommst Du die Device-Bezeichner hin?
>
> Da es ursprünglich als HVM installiert war, hiessen die Partitionen hda*
> Nach dem Wechsel von der HVM zur PVM mit dem -virt kernel musste ich die
> Namen der Partitionen zu xvda* ändern.
>

Ah, OK ich habe auf dieser Maschine leider nicht die Möglichkeit HVM zu 
machen, da mir die Kernelunterstützung fehlt. Ich kann nur PVM.

Aber ich habe noch eine Zweite hier stehen die das können müsste. 
Vielleicht komme ich ja damit weiter.

>
>>> eis3 # mount
>>> /dev/xvda3 on / type ext3 (rw,errors=remount-ro,acl,user_xattr)
>>> /dev/xvda1 on /boot type ext3 (rw,errors=remount-ro)
>>> devpts on /dev/pts type devpts (rw)
>>> usbfs on /proc/bus/usb type usbfs (rw)
>>> /sys on /sys type sysfs (rw)
>>>
>>> eis3 # cat /proc/version
>>> Linux version 3.2.54-eisfair-1-VIRT (root at kernel32) (gcc version 4.5.4
>>> (GCC) ) #1 SMP Tue Sep 16 14:01:22 CEST 2014
>>>
>>> eis3 # cat /boot/grub/grub.conf
>>> timeout 10
>>> default 0
>>> title EisFair1 (virt)
>>>     kernel /kernel root=/dev/xvda3 rootdelay=10 panic=10 ro
>>>     initrd /initrd.gz
>>
>> Das klappt bei mir auch, aber eben auf einem Eis, denn ich mehr oder
>> weniger "händisch zusammen kopiert" habe. Vermutlich geht deshalb auch
>> kein Kernelupdate hin.
>
> Bei RedHat und Klonen ist es so, dass man den Kernel auf dem BareMetal
> und den VMs genau gleich installiert.
> Der pygrub sucht aus dem Partitionierten Image die Boot-Partition,
> extrahiert daraus den aktuellen Kernel (mit initrd) und startet ihn.
>
> Wie grub es auf dem BareMetal auch tut ;-)

OK, BereMetal kenne ich gar nicht, da müsste ich mich erst mal einlesen.
mit CentOS und REDHEAD verhält es es sich ebenso, ich habe damit zwar 
schon mal kurz experimentiert, aber das war es dann auch schon.

Aber was nicht ist, kann ja noch werden. ;-)

Ich verwende zur Zeit Debian 7 bzw. 8 mit xen 4.1 bzw. xen 4.4 auf einer 
anderen Maschine.

[..]

>
>>>>> Beim update vom 'smp/pae' zum 'virt' kann man den lilo noch nutzen.
>>>>> Vom 'virt' zum nächsten 'virt' macht es higegen keinen sinn irgedwelche
>>>>> Booteinträge auf die Platte zu schreiben, allenfalls die grub.conf
>>>>> aktualisieren.
>>>>
>>>> Siehe oben, die dürfte der virtuelle eisfair weder lesen noch schreiben
>>>> können. Das Kernel-Update muss für Systeme auf Blech sicher stellen,
>>>> dass eine gültige alte lilo.conf existiert. Denn diese alte lilo.conf
>>>> wird beim Update für das Schreiben der neuen lilo.conf herangezogen -
>>>> und ist diese falsch, startet eisfair auf Blech nicht mehr...
>>>
>>> Ein E1 als Hardware VM (HVM) bootet ebenfalls via lilo wie auf dem bare
>>> Metal. Hier trifft deine Aussage zu 100% zu.
>>
>> Hier liegen vermutlich meine Probleme, dass ist mir nicht wirklich klar!
>
> Bei einer HVM wird die VM wie ein normaler Rechner gestartet, könnte
> also auch ein Windows sein.
>
> [root at xen ~]# cat /etc/xen/win2000
> name = "win2000"
> uuid = "............."
> maxmem = 256
> memory = 256
> vcpus = 1
> builder = "hvm"
> kernel = "/usr/lib/xen/boot/hvmloader"
> boot = "c"
> pae = 1
> acpi = 0
> apic = 0
> localtime = 1
> on_poweroff = "destroy"
> on_reboot = "restart"
> on_crash = "restart"
> device_model = "/usr/lib64/xen/bin/qemu-dm"
> usbdevice = "tablet"
> sdl = 0
> vnc = 1
> vncunused = 0
> vncdisplay = "31"
> disk = [ "phy:/dev/distro/win2000,hda,w", ",hdc:cdrom,r",
> "phy:/dev/work/win2000data,hdd,w" ]
> vif = [ "mac=00:16:3e:01:23:45,bridge=xenbr0,script=vif-bridge" ]
> serial = "pty"
>

OK, dass ist erst einer der nächsten Schritte. Da HVM auf meiner 
Testmaschine eh nicht geht.

>
> Bei einer PVM kann man den kernel (und initrd) direkt in die Konfig
> hineinschreiben, falls die Dateien in der Dom0 vorhanden sind, oder wie
> weiter oben beschrieben den pygrub Bootloader nutzen.
>
> [root at xen ~]# cat /etc/xen/eis3
> name = "eis3"
> uuid = "............"
> maxmem = 256
> memory = 256
> vcpus = 1
> bootloader = "/usr/bin/pygrub"
> pae  = 1
> acpi = 1
> apic = 1
> on_poweroff = "destroy"
> on_reboot = "restart"
> on_crash = "restart"
> vfb = [ "type=vnc,vncunused=1" ]
> disk = [ "phy:/dev/distro/eis3,xvda,w" ]
> vif = [ "mac=00:16:3e:01:23:45, bridge=xenbr2, script=vif-bridge" ]
>

Wie würde so eine Datei für eine Installation von Eis bei Dir aussehen?
Also z.B. aus einem Original Image?
Würde das überhaupt gehen?

>
>>> Das spielt allerdings keine Rolle bei einer Para VM (PVM), die werden
>>> immer von "aussen" gebootet.
>>>
>>> Entweder wie beim EisXen der den kernel und initrd in der Dom0 gelagert
>>> hat (WIMRE), was sich allerdings nicht auf breiter Front durchgesetzt
>>> hat, oder wie die "Anderen" eine Installation auf ein partitioniertes
>>> Festplattenimage (oder mehrere einzelne Dateien) machen.
>>>
>>> Bei letzteren wird mittels der vom ausserhalb agierenden pygrub
>>> ermittelten kernel und initrd gebootet, die innerhalb vom Plattenimage
>>> liegen, genauso wie die grub.conf.
>>>
>>> Der pygrub ersetzt einen in der PVM installierten Bootlader, und nutzt
>>> die Konfiguration innerhalb der PVM.
>>
>> Genau diesen Ansatz würde ich gern nutzen.
>
> Ich nutze es auf CentOS 5, da ist das von hause aus so.

Da ist XEN schon von hause aus drin?

>
>
>>> Den Kernel installiert man wie gehabt, und für diejenigen die den pygrub
>>> nutzen können, ist eine passende grub.conf in /boot/grub eine nette
>>> Dreingabe, da man kernel und initrd nicht nach jedem Update auf die Dom0
>>> kopieren muss.
>>>
>>> Ist /boot eine eigenständige Partition, dann wird /kernel und /initrd.gz
>>> in der grub.conf eingetragen. (wie in meinem Fall)
>>>
>>> Wenn /boot auf / liegt, muss man /boot/kernel und /boot/initrd.gz
>>> eintragen. In dem Fall müsste / als bootbar markiert sein.
>>>
>>> Bei unpartitionierten Images bleibt einem nichts anderes übrig als den
>>> kernel und initrd von Hand auf die Dom0 zu kopieren. (ohne gewähr)
>>>
>>
>> Was bedeutet "unpartitionierten Images", was meinst Du damit?
>> Nur die Daten mit z.B. dd in ein Image kopiert?
>
> Wenn nur ein Dateisystem (ext3, ext4, reiser....) darin ist, das man
> z.B. mit
> mount /dev/distro/eis3 /mnt
> normal mounten kann.
>

Ah, also nur eine einzelne Partition, oder?

>
> Bei partitionierten Images wird es etwas komplexer:
>
> [root at xen ~]# fdisk -l /dev/distro/eis3
> Platte /dev/distro/eis3: 4294 MByte, 4294967296 Byte
> 255 heads, 63 sectors/track, 522 cylinders
> Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes
>
>            Gerät    boot.  Anfang   Ende     Blöcke   Id  System
> /dev/distro/eis3p1   *        1      6       48096+  83  Linux
> /dev/distro/eis3p2            7     24      136192   82  Linux Swap /
> Solaris
> /dev/distro/eis3p3           24    523     4008960   83  Linux
>
> [root at xen ~]# bin/help-mount-image.sh /dev/distro/eis3
> Warnung, /dev/distro/eis3 ist kein File
>
>   /dev/distro/eis3p1 63 96255 48096+ 83 Linux
> mount -o loop,ro,offset=32256 /dev/distro/eis3 /mnt
>
>   /dev/distro/eis3p2 98304 370687 136192 82 Linux swap / Solaris
> Ignoriere Swap
>
>   /dev/distro/eis3p3 370688 8388607 4008960 83 Linux
> mount -o loop,ro,offset=189792256 /dev/distro/eis3 /mnt
>

OK, hier habe ich das Gefühl das hier noch mit "DOS-Typ" gearbeitet 
wird. Bei mir spielt da schon GPT mit. Das von Dir gezeigte Script gibt 
es unter Debian nicht. Aber ich glaube, dass ich das auch mit "kpartx" 
erledigen kann. Beispiel (Passt zum Versuch von oben):
root at deb64-xen:/etc/xen# kpartx -l /dev/vg1/eis1-7
vg1-eis1--7p1 : 0 98304 /dev/vg1/eis1-7 2048
vg1-eis1--7p2 : 0 262144 /dev/vg1/eis1-7 100352
vg1-eis1--7p3 : 0 2097152 /dev/vg1/eis1-7 362496
vg1-eis1--7p4 : 0 31074271 /dev/vg1/eis1-7 2459648

kpartx kann auch Loop mounten.

(Das ist so ein Punkt, an dem ich arbeiten möchte)
>
>>> Das kernel Update geschieht bei allen drei Varianten auf die gleiche
>>> Weise wie auf einem physischen Rechner.
>>>
>>> Weitergehende Installationen wie lilo, grub und was es sonst noch so
>>> gibt laufen ohnehin ins leere, die Mühe kann man sich sparen.
>>>
>>>
>>> Ich hoffe, ich konnte dir einen brauchbaren Überblick vermitteln. ;-)
>>
>> Ja, zumindest in weiten Teilen!
>> Was mich brennend interessiert, ist, wie installierst Du einen frischen
>> Eis in eine DomU?
>
> Siehe weiter oben...

Was meinst Du jetzt genau, das habe ich jetzt nicht ganz verstanden, 
sorry. Oder bin ich zu Blind? ;-)

>
>
>> Einfach über ein Insatllations-Image bekomme ich das nicht hin. Das wird
>> zwar gestartet, ein Netzwerkkartentreiber wird gefunden und eine IP wird
>> vom DHCP geholt. Aber dann wird nach einem Installationsmedium gesucht
>> und das geht schief. Warum, weiß ich leider nicht.
>
> Was hast du wie versucht?
> Bitte möglichst _genau_ beschreiben, ev. Konfiguration dazu posten.
>

Einen Teil habe ich ja oben schon beschrieben, aber das ist noch nicht 
alles. Nur ich möchte nun erst mal alle Deine Tips zum mounten usw. 
genauer unter die Lupe nehmen um vielleicht dabei eine Lösung zu finden. 
Ich habe in Deinen Beschreibungen doch so das ein oder andere gefunden 
was ich gern ausprobieren möchte.

Ich werde dann aber gern darauf zurückkommen, wenn ich darf, wenn ich 
mit meinen "Forschungen" nicht weiter komme. Eventuell setze ich mir 
auch noch mal ein Testsystem mit VT-Unterstütztung auf.

>
>> Über die ein oder andere Hilfestellung würde ich mich riesig freuen.
>> Ich versuche mich da schon etwas länger dran...
>>
>> Ich würde gern eine Installations- und Administrations-Methode finden
>> und dann auch gern Dokumentieren damit alle etwas davon haben.
>
>
> Da ich Xen, wie schon erwähnt, nur unter CentOS nutze, kann ich Dir
> vermutlich nur Hilfe zu allgemeinen Fragen anbieten.
>

Du hast ein CentOS mit Grafischer Unterstützung, richtig?
Wenn ich noch einen Rechner mit VT finde, werde ich das wohl mal 
probieren. Aber mein Ziel ist das nicht, ich möchte einen Server ohne 
Grafik. Aber wenn es hilft, diese Thematik besser zu verstehen...

Nochmal recht herzlichen Dank für Deine ausführliche Antwort!!


-- 
Gruß,
Helmut