XenServer 6.1: neuer Kernel - sda->xvda. Umbiegen möglich?

[Pizzaesser]

Ich beschäftige mich mit meinem bis vor kurzem kaum vorhanden XEN-Wissen an einer Lösung zu folgender Problematik:

Ich habe hier einen Collax Business Server mit Kernel 2.6.32 als domU (HVM) laufen.
Beim (automatischen) Update auf die neueste Version des CBS wird u.a. auch ein 4.4er Kernel installiert. Nach dem notwendigen Neustart kann Grub sda3 nicht finden und das System hält mit Kernel Panic. Ursächlich scheint zu sein, dass die Partitionen nun vom System nicht mehr als sdax, sondern xvdax (Paravirtualized virtual...) erkannt werden.
Unter VirtualBox ist dies nicht der Fall.


Grundsätzlich gibt es mit dem Updateprozess kein Problem, unter VirtualBox lief testweise alles wie gewünscht.

Ich habe nun versucht in der Grub-Config sda3 durch xvda3 zu ersetzen (was das System schon mal booten lässt) und die fstab entsprechend anzupassen, aber aus irgendwelchen Gründen finden die direkt beim ersten Neustart durchlaufenden Konvertierungsscripte (CBS wechselt von Zarafa auf Kopano) Verzeichnisse wie /var nicht mehr.

Ich denke es wäre sinnvoll, wenn die VM die Virtual Disks einfach nach dem althergebrachten Namensschema erkennen würde.

Ausgehend von den älteren Xen Versionen mit editierbarer Configdatei zu jeder VM unter /etc/xen/ habe ich an den "Disks" Parameter der VM gedacht.

Beispiel:

#----------------------------------------------------------------------------
# Define the disk devices you want the domain to have access to, and
# what you want them accessible as.
# Each disk entry is of the form phy:UNAME,DEV,MODE
# where UNAME is the device, DEV is the device name the domain will see,
# and MODE is r for read-only, w for read-write.

#disk = [ 'phy:hda1,hda1,r' ]
disk = [ 'file:/var/images/min-el3-i386.img,hda,w', ',hdc:cdrom,r' ]

Dieser ist aktuell wohl nicht gesetzt:

[root@xenserver1 var]# xe vm-param-get uuid=21cb0a3c-4bc9-f749-5046-032b7651d378 param-name=disks
<not in database>

Ich habe zwar ein HowTo zu ähnlicher Problematik gefunden, scheitere bei der Umsetzung aber an der unter 6.1 nicht mehr vorhandenen Konfigurationsdatei unter "/etc/xen/<guest>":
https://wiki.xenproject.org/wiki/Xen_Common_Problems#I_upgraded_PV_domU_from_old_Xenlinux_kernel_to_new_pvops_kernel.2C_and_now_the_domU_doesn.27t_work_anymore.21

Ist es irgendwie möglich, die VM mit neuem Kernel weiterhin die althergebrachten Partitionsbezeichnungen erkennen zu lassen?

 

[b1nb4sh]

Hallo,

wie jedes Linux System erfolgt die Namensgebung der Festplatten durch udev.

Kann es sein, dass eine neue udev Konfigdatei existiert und daher die Umbenennung erfolgt?

Hier ein Beispiel

# vi /etc/udev/rules.d/00-corrections.rules

KERNEL=="sd?", ATTRS{model}=="SAMSUNG SP0411N", NAME="sda"
KERNEL=="sd??", ATTRS{model}=="SAMSUNG SP0411N", NAME="sda%n"
KERNEL=="sda", ATTRS{model}!="SAMSUNG SP0411N", NAME="sdb"
KERNEL=="sda?", ATTRS{model}!="SAMSUNG SP0411N", NAME="sdb%n"

 

[Pizzaesser]

Hallo, danke für die Anregung.
Ich weiß zwar noch nicht ob das Fummeln innerhalb der VM der richtige Ansatz ist, aber zumindest die vorhandenen Dateien unterscheiden sich.

Vor dem Update:

admin@cbs:/etc/udev/rules.d$ dir
total 88
-rw-r--r-- 1 root root   546 Apr 22  2010 45-devmapper.rules
-rw-r--r-- 1 root root  1339 Nov 30  2011 50-misc.rules
-rw-r--r-- 1 root root  4277 Nov 30  2011 50-udev-default.rules
-rw-r--r-- 1 root root   141 Nov 30  2011 60-cdrom_id.rules
-rw-r--r-- 1 root root  1099 Aug 13  2009 60-pcmcia.rules
-rw-r--r-- 1 root root  1431 Nov 30  2011 60-persistent-input.rules
-rw-r--r-- 1 root root  1396 Nov 30  2011 60-persistent-storage-tape.rules
-rw-r--r-- 1 root root  3855 Nov 30  2011 60-persistent-storage.rules
-rw-r--r-- 1 root root   540 Nov 30  2011 60-persistent-v4l.rules
-rw-r--r-- 1 root root   518 Nov 30  2011 61-persistent-storage-edd.rules
-rw-r--r-- 1 root root 11076 Jul 14  2016 62-nut-usbups.rules
-rw-r--r-- 1 root root   156 Feb 15  2016 70-aacraid.rules
-rw-r--r-- 1 root root   390 Nov 30  2011 75-cd-aliases-generator.rules
-rw-r--r-- 1 root root   143 Nov 30  2011 79-fstab_import.rules
-rw-r--r-- 1 root root   842 Nov 30  2011 80-drivers.rules
-rw-r--r-- 1 root root  1353 Apr 22  2010 90-blkid.rules
-rw-r--r-- 1 root root  1456 Nov 30  2011 95-kpartx.rules
-rw-r--r-- 1 root root   325 Nov 30  2011 95-multipath.rules
-rw-r--r-- 1 root root   234 Nov 30  2011 95-udev-late.rules

Nach dem Update:

admin@cbs:/etc/udev/rules.d$ dir -l
total 120
-rw-r--r-- 1 root root  1577 Feb 22  2016 11-dm-mpath.rules
-rw-r--r-- 1 root root   764 Jan 25  2015 42-qemu-usb.rules
-rw-r--r-- 1 root root    68 Apr 13 18:42 45-misdn.rules
-rw-r--r-- 1 root root  1232 Jan 25  2015 50-misc.rules
-rw-r--r-- 1 root root  3665 Jan 25  2015 50-udev-default.rules
-rw-r--r-- 1 root root   646 Jan 25  2015 60-cdrom_id.rules
-rw-r--r-- 1 root root  1099 Aug 13  2009 60-pcmcia.rules
-rw-r--r-- 1 root root   616 Jan 25  2015 60-persistent-alsa.rules
-rw-r--r-- 1 root root  2400 Jan 25  2015 60-persistent-input.rules
-rw-r--r-- 1 root root   947 Jan 25  2015 60-persistent-serial.rules
-rw-r--r-- 1 root root  1420 Jan 25  2015 60-persistent-storage-tape.rules
-rw-r--r-- 1 root root  5973 Jan 25  2015 60-persistent-storage.rules
-rw-r--r-- 1 root root   769 Jan 25  2015 60-persistent-v4l.rules
-rw-r--r-- 1 root root   166 Jan 25  2015 61-accelerometer.rules
-rw-r--r-- 1 root root 11078 Feb 24  2016 62-nut-usbups.rules
-rw-r--r-- 1 root root  2134 Sep 25  2015 63-md-raid-arrays.rules
-rw-r--r-- 1 root root  1366 Sep 25  2015 64-md-raid-assembly.rules
-rw-r--r-- 1 root root   156 Feb 15  2016 70-aacraid.rules
-rw-r--r-- 1 root root   570 Jan 25  2015 75-net-description.rules
-rw-r--r-- 1 root root   255 Jan 25  2015 75-probe_mtd.rules
-rw-r--r-- 1 root root   570 Jan 25  2015 75-tty-description.rules
-rw-r--r-- 1 root root  4174 Jan 25  2015 78-sound-card.rules
-rw-r--r-- 1 root root   565 Jan 25  2015 80-drivers.rules
-rw-r--r-- 1 root root  1190 Jul 23  2016 90-blkid.rules
-rw-r--r-- 1 root root  2187 Feb 22  2016 95-kpartx.rules
-rw-r--r-- 1 root root   155 Jan 25  2015 95-udev-late.rules

Edit: Ich denke, es müsste direkt an der VM-Config angesetzt werden. Ich kann auf der betreffenden VM nicht mal eine Neuinstallation des CBS vornehmen, da keinerlei Datenträger als Installationsziel erkannt werden. Lsblk zeigt währenddessen jedoch vorhandene /dev/xvda Einträge. Der Umgang mit solchen durch den neuen Kernel als virtuell erkannten Volumes scheint einfach nicht vorgesehen zu sein.

 

[Pizzaesser]

...mit Version 7.0.22 hatte Collax die Probleme des CBS mit dem XEN Host gefixt:

Release Notes CBS 7.0.22

Hardware: PV-Storage-Device für Xen-Unterstützung​

Im PV-Modus stellt Xen seine virtuelle Festplatte mittels /dev/xvda dem installierten Betriebsystem der virtuellen Maschine zur Verfügung. Mit diesem Update unterstützen Collax Server auch die Installation auf /dev/xvda Devices.