Beiträge von dernachtwerker

20.Dez.2023

Interner Fehler: libxenlight konnte neue Domain 'xxx-opensuse15.5-versuch-1' nicht erstellen

Irgendwann hat sich etwas zerstückelt, was ist nicht bekannt.

Der Server : XEN basierter opensuse (von 15.1 bis) 15.6 mit 1 SSD und 8 GB RAM und Intel i5 -

6 Raw-Partitionen für opensuse VMs vorbereitet, davon 3 VMs installiert und nach wie vor aktiv

Hostsystem online Upgrade mit 3 laufenden VMs von 15.2 ... auf 15.5 ging voll daneben, weil instabil,

sofortiges offline upgrade auf 15.6 Alpha erforlgreich - läuft wieder stabil.

alle 3 aktiven VMs werden beim Reboot automatisch sauber runter gefahren und auch wieder sauber hochgefahren

Diese XEN Installation ist also von Leap 15.1 bis 15.6 durchgelaufen

Bei einer xbeliebigen VM Installation (virt-install) kommt folgender Fehler :

Beispiel :

Unable to complete install: 'Interner Fehler: libxenlight konnte neue Domain 'md3-opensuse15.5-versuch-1' nicht erstellen'

Traceback (most recent call last):

File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper

callback(asyncjob, *args, **kwargs)

File "/usr/share/virt-manager/virtManager/createvm.py", line 2081, in _do_async_install

installer.start_install(guest, meter=meter)

File "/usr/share/virt-manager/virtinst/install/installer.py", line 734, in start_install

doboot, transient)

File "/usr/share/virt-manager/virtinst/install/installer.py", line 680, in _create_guest

domain = self.conn.createXML(install_xml or final_xml, 0)

File "/usr/lib64/python3.6/site-packages/libvirt.py", line 4376, in createXML

raise libvirtError('virDomainCreateXML() failed')

libvirt.libvirtError: Interner Fehler: libxenlight konnte neue Domain 'md3-opensuse15.5-versuch-1' nicht erstellen

Also verblieb nur die brutale Tour :

Downgrade auf 15.5 und neuer Versuch - unerfolgreich

Downgrade auf 15.4 und neuer Versuch - unerfolgreich

Downgrade auf 15.3 und neuer Versuch - unerfolgreich

Deinstallation von XEN samt aller XEN Tools und libvirt bei allen Versuchen -

jeweils Neustart und Neuinstallation von XEN und Xen-Tools sowie python mit zypper ---force

Es werden ja python Programme angemeckert.

dann wieder die upgrades auf 15.4 und 15.5 und 15.6 (immer von den lokal verfügbaren 4,5 GB ISOs - das geht sehr schnell)

Bei jedem Neustart in jeder dieser Versionen sind alle 3 aktiven VMs sauber gestartet - also problemlos gestartet

denoch - auch in der 15.6 mit neuem erzwungenen python und neuen XEN-Tools kann ich keine weitere VM installieren.

Es kommt immer der gleiche Fehler - siehe zwei Bilder im Anhang

Wo soll ich anpacken ? Welches Repo liefert diese python Programme und warum werden die, wenn sie defekt wären, bei up- oder downgrades nicht überschrieben ?

vielen Dank fürs Mitdenken

Gert Redlich Wiesbaden

2 Screenshots im Anhang

XEN-Server - Subpartitionen werden nicht mehr angezeigt ???

Existierendes Ssystem :

Opensuse von 15.1 upgraded bis aktuell 15.6 - virtualisiert mit XEN 4.18 und 2 oder mehr VMs eingerichtet

Hardware : Intel I5 - 16GB RAM

1 SSD- 1TB Festplatte mit 3 Partitons für den Host + 3 oder mehr RAW-Partitionen für die VMs

- die ersten 3 sind primary Partitionen (für das Host-System = DOM-0)

und die folgenden 2 oder mehr RAW-Partitionen (ca. 120 GB) haben jeweils 3 Subpartitionen

Eine VM bekommt bei mir immer eine dedizierte RAW Partion zugeordnet und

dort drinnen wird mit dem YAST Installer das Gast-System (von opensuse 12.3 bis 15.6 - kein WIndows) angelegt.

Solch eine neue VM bekommt dabei 1GB "/boot" - dann 4GB "Swap" und den Rest als "/root" - also mindestens 3 (Sub)-Partitionen

Bei XEN-Installationen mit RAID-1 konnte ich - auf Host-Ebene - mit dem YAST Partitionierer - sowohl die Haupt-Partitionen

wie auch die jeweiligen 3 Subpartitonen unterhalb einer DOM-U Partition sehen. Das ging auch mit "lsblk".

Auf dem Host ohne RAID-1 kann ich diese Subpartitonen nicht mehr sehen, weder im Partitionierer noch mit lsblk :

Beispiel : hier ein altes Muster-Beispiel einer XEN Installation mit 2 RAID-1 Platten

│ └─md4 9:7 0 40G 0 raid1

│ ├─md4p1 259:7 0 2G 0 part swap

│ ├─md4p2 259:8 0 18G 0 part root

│ └─md4p3 259:9 0 20G 0 part

auch im Yast Partitionierer waren diese Subpartitionen alle zu sehen

=========================================================

Auf einer Installation ohne RAID (also mit nur 1 SSD) sieht es mit "lsblk" so aus :

[DOM0-Wiesbaden-i5-root] ~ $ lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS

sda 8:0 0 232.9G 0 disk

├─sda1 8:1 0 2G 0 part /boot

├─sda2 8:2 0 2G 0 part [SWAP]

├─sda3 8:3 0 50G 0 part /

├─sda4 8:4 0 1K 0 part

├─sda5 8:5 0 120G 0 part >>>>>>>>>> hier muss ich rein schaun können

└─sda6 8:6 0 58.9G 0 part

das reine "fdisk -l" zeigt folgendes an

[DOM0-Wiesbaden-i5-root] ~ $ fdisk -l

Device Boot Start End Sectors Size Id Type

/dev/sda1 * 2048 4196351 4194304 2G 83 Linux

/dev/sda2 4196352 8390655 4194304 2G 82 Linux swap / Solaris

/dev/sda3 8390656 113248255 104857600 50G 83 Linux

/dev/sda4 113248256 488397167 375148912 178.9G f W95 Ext'd (LBA)

/dev/sda5 113250304 364908543 251658240 120G 83 Linux

/dev/sda6 364910592 488397167 123486576 58.9G 8e Linux

und das Beispiel-Device "sda5" - jetzt als Option "/dev/sda5" direkt angesprochen - zeigt die subpartitions

[DOM0-Wiesbaden-i5-root] ~ $ fdisk -l /dev/sda5

Device Boot Start End Sectors Size Id Type

/dev/sda5p1 2048 4208639 4206592 2G 82 Linux swap / Solaris

/dev/sda5p2 * 4208640 130045951 125837312 60G 83 Linux

/dev/sda5p3 130045952 251658239 121612288 58G 83 Linux

Da sind also meine Subpartitionen in "sda5" !!!!

Auf dem Host (als root (su)) kann ich diese Subpartitionen aber nicht mounten.

Auch in "/dev/" sind sie nicht zu sehen. - Und das ist ganz schlecht.

Was läuft da falsch oder was fehlt bei den Treibern oder Parametern ?

Wo ist der Trick ? oder was ist mir entgangen ?

vielen Dank für Ihr Mitdenken

Gert Redlich Wiesbaden

18.7.2023 - Ein Kommentar

Darüber bin ich auch gestolpert und das ist eine sehr unverständliche Stategie. Alle Linuxer jammern und schimpfen über Microsoft und WIN 7 bis WIN 11 und jetzt sind wir genau dort angekommen. Die ganzen angegebenen Hilfskrücken sind viel zu aufwendig, als daß ein Profi sich damit runschlagen will. Der hat ganz andere Sorgen. Warum hat man das nicht leben lassen ? . Es hatte doch jetzt weit über 15 Jahre leidlich funktioniert und über putty getunnelt war es auch sicher. Bis Leap 15.3 hatte ich den vncserver auf der DOM 0 unter XEN und KVM am Laufen, So unterminiert man die sowieso schon schwindende Basis von opensuse nach weiter. Ich mußte mich mit MS Server 2018 rumschlagen. Gegen dieses Grafik-Monster hat opensuse jetzt fast keine Argumente mehr außer - das haben wir schon immer so gemacht. Sehr schade.
Bei der Default 15.5 NET Installation auf einer frischen Platte und gleich danach Umstellung auf den 15.5 XEN Kernel loopt der Login Vorgang auf ewig. Also neu booten und zurückstellen auf NON XEN STandard Kernel und alle Updates fahren und noch mal probieren, aha, dann geht es . Welchem Kunden soll ich sowas erklären ?

Editiert von Administrator

Guten Abend an alle opensuse 13.2 xen Profis :

nachdem ich die überflüssigen Hürden der DOM-0 Installation von 13.2 geschafft habe, will die einfachste DOM U nicht starten. Zum Glück laufen alle Produktions-Server mit der 12.3 als DOM-0 stabil und sauber, auch mit 13.2 Gästen. Also im Prinzip geht es - würde Radio Eriwan melden. Doch mit der 13.2 als DOM 0 zickt das System.

Hier habe protokolliert, wie ich es seit einiger Zeit mit den anderen xen-Servern ja auch gemacht habe - einfach (fast) alles durchwinken. - es sind jede Menge fortlaufender Screenshots über den Fortgang dabei. - http://software.rde.de/1116.html

Es scheint irgend ein Emulations-Modul zu fehlen, anders kann ich es mir nicht erklären. Ein Vergleich mit den laufenden Servern unter der Version 12.3 brachte keine weitere Erkenntnis, wo ich suchen soll.

Bei wem laufen denn die 13.2 Gäste auf einer 13.2 DOM-0 - ich könnte eine Liste der installierten virtlib und xen Module der DOM-0 gebrauchen, denn da fehlt doch etwas. (Meine DOM-0 ist gestern am 23.2.2015 nochmal völlig neu aufgesetzt worden und mit "zypper up" tagesaktuell am Laufen.)

vielen Dank für Tips und Tricks,

der nachtwerker

Danke, mache ich
Gert

"Bei mir ist er automatisch in jeder 13.1 oder 13.2- Installation drin"..... usw .....

Hallo an alle, vielen Dank, ja das ist nach "Radio Eriwan" richtig, aber schaut bitte mal hier rein:

http://software.rde.de/1112.html

vergleicht bitte mal den 1. Screenshot und den 2. Screenshot,

im ersten Bild (opensuse Version 12.3) wird ganz oben (1. Menüpunkt) der "virt-install" geladen
und in dem rot umrahmten 4. Menüpunkt der "virt-manager".
Das ist sehr übersichtlich und auch in Stressituationen ganz leicht zu bedienen

In dem unteren Bild (opensuse Version 13.2) wird der "virt-install" mit Hilfe des "virt-managers" geladen,
wobei ich - wenn ich das weiß - den Installvorgang ja nur abbrechen muß, um dann doch im "virt-manager" zu landen.

Doch das ist alles nur ein Klimmzug, das muß doch nicht sein. Meine Sub-Admins - die das nur im Notfall machen sollten - finden das überhaupt nicht mehr lustig.

Darum die ganz simple Frage :

Wie kann ich in yast eigene Menüpunkte einbinden / ergänzen, z.B. auch den "gparted"

vielen Dank

dernachtwerker

(24. Feb. 2015) Seit opensuse 13.1 ist in der DOM 0 (xen) der virt-manager nicht mehr im yast- (und auch nicht im yast2-) Untermenü "virtualisierung" enthalten. Bis zur Version 12.3 war das alles ok.

Frage 1. warum nicht mehr ?
Frage 2. Wie bekomme ich den VMM wieder ins yast Menü ?

Auch googlen hilft nicht weiter - meine Suchfrage war : "add virt-manager to yast menu"

Wo finde ich das howto, um das yast menu mit Systemprogrammen wie dem virt-manager zu ergänzen ?

Danke für jeden Tip oder Link
dernachtwerker

Erläuterung:
Ich habe zur Zeit 3 Produktions-Server (4 Kerne) mit 12.1 XEN/64 und einen mit 12.3 XEN/64 und den neuen 8 Kern Server mit 13.1 XEN/64 am Laufen. Auf allen Servern ist kein KDE und kein GNOME, sonder nur X11 drauf - und das nur wegen der XEN Admin Tools.
Auf allen Servern arbeite ich sowohl mit Yast (ncurses) über die putty Text-Konsole als auch mit Yast2 in der graphischen VNC Konsole.
Weiterhin habe ich einen AMD 64 Dual Core PC mit 4 LCD Schirmen und 4 Grafikarten.
Somit kann ich mir auf die Bildschirme 2 x putty und 2 x VNC legen und ausgiebig vergleichen.
Auf dem Notebook laufen 2 "putty"s mit htop, wegen der CPU Auslastung. Alles mit Gigabit Ethernet und VDSL Anbindung, also in der Regel extrem schnell.
Soweit zur Kontrolle der Lasten und der Zeiten, denn mit Gefühl kann man nichts beweisen.

Auf den 12.1 und 12.3 Server gehen beide YAST Versionen etwa gleich schnell ab, jeweils bis zum beendeten Maskenaufbau. Auf der 13.1 Suse lahmt die yast Textversion, die grafische yast2 geht gut ab, also deutlich schneller.

Ich werde mal Ruby nochmal drüber klatschen, mal sehen.

Danke, ist auf der Webseite korrigiert, doch warum ist YAST jetzt so elend langsam,
Ladezeit zur Installation von Software fast 1 volle Sekunde, früher nicht mal eine 10tel Sekunde ?

Hallo Sever-Admins,
bei mir laufen mehrere HP DL385 G1 (4 Opteron Kerne a 2,2 GHz und 16 Gig RAM),
jeweils mit 12.1 XEN und 12.2 XEN. - yast geht ab wie die Feuerwehr, also wirklich schnell und rasant

jetzt habe ich einen DL385 G2 (8 Opteron Kerne und 32 GigRAM) und 13.1 /64 aufgesetzt und es ging anfänglich gerade mal akzeptabel schnell, jetzt nach Abschluss aller Updates aber extrem langsam
als unakzeptabel langsam
eine CPU (von 8 - mit htop bewacht) baggert Sekunden mit 100% rum, bis die Software Installation aufgeht.
habe die automatischen Update bereits drastisch reduziert

kann das jemand bestätigen oder hat jemand auch diese Erfahrung ??

und jetzt der Hammer:
unter tightVNC und X11 geht in der VNC Konsole die yast2 Version erheblich schneller, als die yast Version innnerhalb von putty

das macht mich sehr nachdenklich
ein ausführliches Installations protokoll habe ich hier angefangen
http://software.rde.de/opensuse-131-auf-dl385-g2-00.html

dernachtwerker