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

[Thomas Zweifel]

Hallo Helmut

Am 17.06.2015 um 21:24 schrieb Helmut Backhaus:
> Hallo Thomas, hallo zusammen,
> sorry, aber ich muss diesen alten Trade noch mal aufwärmen.
> Mir stellen sich hier einige Fragen und ich hoffe hier vielleicht die
> eine oder andere Antwort zu bekommen.
> 
> Wenn das hier nicht OK ist, mache ich auch gern einen Neuen Trade auf.
> 
> 
> Am 21.11.2014 um 04:31 schrieb Thomas Zweifel:
>> Am 21.11.2014 um 00:10 schrieb Thomas Bork:
>>> Am 20.11.2014 um 22:33 schrieb Thomas Zweifel:
>>>
>>>> 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.

Ä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.

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.


>> 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 ;-)


>> [root at xen ~]# lvdisplay /dev/distro/eis3
>>    --- Logical volume ---
>>    LV Name                /dev/distro/eis3
>>    VG Name                distro
>>    LV Write Access        read/write
>>    LV Status              available
>>    # open                 2
>>    LV Size                4,00 GB
>>    Current LE             256
>>    Segments               2
>>
>>
> 
> Auch das sieht bei mir ähnlich aus.

:-)

>>>> 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"


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" ]


>> 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.


>> 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.


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


>> 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...


> 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.


> Ü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.




Gruss Thomas