Upgrade Laptop to Opensuse 42.3, Probleme mit Bumblebee und VMware WS 12.5, Workarounds

Gestern war ein Upgrade meines nun schon in die Jahre gekommenen Laptops von Opensuse Leap 42.2 auf Leap 42.3 fälllig.
Ich bin dabei gem. der schönen Anleitung in
https://kamarada.github.io/en/2017/08/03/how-to-upgrade-from-opensuse-leap-422-to-423/
vorgegangen. Zu der Anleitung gibt es nichts weiter zu sagen; die ist perfekt. Im Upgrade hatte ich nur die Standardrepositories (inkl. Update-Repository) für Leap 42.3 benutzt.

Mein Laptop hat eine Nvidia-Karte (Optimus-System). Das ursprüngliche Leap 42.2 lief auf dem Laptop deshalb mit einer Bumblebee-Installation; das funktionierte einwandfrei. Zudem nutzte ich auf dem Laptop VMware WS 12.5. Nach dem Leap-Upgrade hatte ich jedoch sowohl mit Bumblebee als auch VMware-Workstation Probleme - obwohl auch Leap 42.3 nur einen Kernel der nun doch schon recht alten Version 4.4 aufweist! nach dem Ugrade war bei mir 4.4.92-31 aktiv; bei der Leap_42.3 war dagegen der Kernel 4.4.76 der Default-Kernel.

Nebenbei: Bzgl. der Kernelversionen hat der SLES-Unterbau von Opensuse Leap plötzlich den unangenehmen Nebeneffekt, dass man an älteren Kernelversionen kleben bleibt ... Von SUSEs Seite müssen ggf. Back-Portierungen aus neuen Kernelversionen zu älteren Versionen vorgenommen werden. Das kann Nebeneffekte zeitigen (s.u.). Bin mal gespannt wie Opensuse mit diesem Thema in Zukunft umgehen will ...

Wiederholte Modul-Einträge in der Datei "/etc/sysconfig/kernel"

Das erste Problem war, dass die Datei "/etc/sysconfig/kernel" nach dem Neustart mehrfache Einträge zum Laden von nvidia-Modulen enthielt. Woher immer das stammte; vielleicht hatte ich das ja schon früher von Experimenten mit Bumblebee drin. Vielleicht wurden die Einträge aber auch im Upgrade hinzugefügt. Jedenfalls mal checken, dass in dieser Datei nach dem Upgrade kein überflüssiger Unsinn drinsteht.

Bumblebee-Installation wieder zum Laufen bringen

Bumblebee lief nach dem Upgrade nicht mehr. Ok, dachte ich, also die für Leap 42.3 passenden Repositories aktivieren und diverse Bumblebee-Pakete aktualisieren. Es gibt jedoch mehrere Repositories mit Bumblebee-Paketen für Opensuse Leap, u.a.
http://download.opensuse.org/repositories/home:/Bumblebee-Project:/nvidia:/3xx.xx/OpenSUSE_Leap_42.3.
Unter Leap 42.1/42.2 hatte ich etliche Pakete aus diesen Repositories benutzt.

Für Leap 42.3 gilt (nach meiner Erfahrung): Zu nutzen ist
http://download.opensuse.org/repositories/X11:/Bumblebee/openSUSE_Leap_42.3
und sonst gar nichts! Auch nicht das Nvidia-Community-Repository!

Die im "X11:Bumblebee"-Repository vorhandenen Pakete - inklusive der Pakete mit dem proprietären Nvidia-Treiber - kann und sollte man dagegen (bis auf eines) installieren; das Paket "primus" habe ich mir allerdings aus dem 42.3-Update-Repository geholt.

Ergänzung 02.12.2017: Wichtige Ausnahme:
bbswitch sollte man nicht installieren. Es reicht bbswitch-kmp-default! Und nur letzteres hat bei mir funktioniert - und zwar ohne dkms-Service.

Die Installation von bbswitch aktiviert den "dkms"-Service; waren sowohl "bbswitch-kmp-default" und "bbswitch" installiert, so führte dies bei mir anhand von Statusanzeigen erkennbar zu einem wechselseitigen An- und Abschalten der Graka im Bootprozess; sie wird danach von den Treibern nicht mehr erkannt.

(Auf die anderen Repositories zu unterschiedlichen Nvidia-Treibern sollte man wirklich nur im Notfall zurückgreifen, und zwar dann, wenn ihr für eure Graka zwingend einen älteren Nvidia-Treiber benötigt; aber auch dann nur x11-video-nvidia installieren. Nicht dagegen das Paket "dkms-nvidia"!)

Zu beachten ist also auch folgender Hinweis: Falls ihr früher einen laufenden dkms-Service hattet: Unbedingt deaktivieren! Und zwar nach der Installation der Pakete, aber schon vor einem anschließenden Neustart des Systems.

systemctl disable dkms

Das steht im Gegensatz zu den Anweisungen in der Anleitung
https://de.opensuse.org/SDB:NVIDIA_Bumblebee
absolut notwendig! Zumindest auf meinem Laptop ... Fragt mich bitte nicht, warum der dkms-Service zu Problemen führt.

Der Bumblebee-Dämon "bumblebeed" dagegen muss über den zuständigen Service aktiviert werden

systemctl enable bumblebeed

Zudem checken, dass der User, unter dem ihr mit einer grafischen Oberfläche arbeitet, Mitglied der Gruppen "video" und "bumblebee" ist. Ggf. mittels "usermod -G video,bumblebee USERNAME" korrigieren.

Dann Neustart des Systems. Die Kommandos

optirun glxspheres
vblank_mode=0 primusrun glxspheres
optirun -b none nvidia-settings -c :8

sollten danach alle einwandfrei funktionieren.

Sollte das nicht der Fall sein und immer noch eine Meldung kommen, dass die Graka nicht vorhanden sei und der "nvidia"-Treiber nicht geladen werden könne:

Alle Pakete aus dem Nvidia-(Community)-Repository (Treiber nvidia-gfx-GL04 und ähnliche), aus dem Nvidia-Bumblebee-Repository und dem oben angegebenen Standard-Bumblebee-Repository löschen. Danach nur die Pakete aus dem oben angegebenen Standard-Repository http://download.opensuse.org/repositories/X11:/Bumblebee/openSUSE_Leap_42.3
mit Ausnahme von bbswitch (!) installieren. Den dkms-Service dann prophylaktisch deaktivieren! Neustart.

Ein probeweiser Start des dkms-Service führt nach einem vorhergehenden Erfolg mit "primusrun" in jedem Fall wieder in die Katastrophe:

Danach kommen in Logfiles Fehlermeldungen, dass es kein passendes Grafik Device gäbe. Am Terminal erscheint: "Cannot access secondary GPU ...". Das ließ sich durch ein anschließendes normales Stoppen des dkms-Service nicht mehr beheben. Bumblebee funktionierte auch nach dem Stoppen des dkms-Service nicht mehr ordnungsgemäß; nvidia Module ließen sich selbst manuell nicht mehr laden. Da half nur ein Reboot - natürlich bei deaktiviertem dkms-Service.

Ich habe leider keine Zeit, der genauen Ursache auf den Grund zu gehen. Bei künftigen Änderungen des Kernels muss man ohne korrekt funktionierendes dkms ggf. halt ein Update für die nvidia- und bbswitch-Module aus dem Bumblebee-Repository erzwingen und damit (zumindest bzgl. nvidia) eine Neukompilation durchführen lassen. Interessant ist, dass für den bei mir nach dem Leap-Upgrade aktiven Kernel 4.4.92-31 ein Link von
/lib/modules/4.4.92-31-default/weak-updates/updatesbbswitch.ko -> /lib/modules/4.4.676-1-default/updates/bbswitch.ko
angelegt wurde. Der funktioniert offenbar. Irgendwas am Kernel 4.4.92 missfällt womöglich dkms beim Versuch, für den neueren Kernel das passende Modul zu definieren. Der 4.4.92-Kernel führt aufgrund von Rückportierungen, die die SuSE-Leute wohl vorgenommen haben, auch noch in anderem Kontext - nämlich bzgl. der VMware WS - zu Schwierigkeiten.

Probleme mit der VMware Workstation 12.5. unter Leap 42.3 beheben

Meine unter Leap 42.2 installierte VM WS 12.5.1 lief nach dem Leap-Upgrade nicht mehr. Auch ein Upgrade der Workstation-SW auf die aktuelle Version 12.5.8 endete beim ersten Startversuch mit Kompilierungsfehlern. Die konnte ich mir im Detail zwar ansehen; wie man aber die problematischen Stellen im Quellcode der VMware-Module beheben hätte müssen, lag jenseits meiner Kenntnisse und Fähigkeiten.

Hier half aber der Beitrag eines offenbar Kernel-Kundigen im VMware Community Forum:
https://communities.vmware.com/message/2693257#2693257
Dort suche man nach dem Beitrag von "hendrikw84"! Herzlichen Dank an diesen Herrn! Seine Vorgaben zur Korrektur diverser Codezeilen funktionieren nämlich einwandfrei. (Ursache der Probleme sind offenbar Rückwärtsportierungen von Features des Kernels 4.10 in den Code des Kernels 4.4. Was immer die SuSE-Leute dabei gedacht haben ...)

[ Warum allerdings die eine vorgeschlagene Korrektur-Zeile

retval = retval = get_user_pages((unsigned long)uvAddr, numPages, 0, ppages, NULL);

nicht gleich zu

retval = get_user_pages((unsigned long)uvAddr, numPages, 0, ppages, NULL);

verkürzt werden kann, ist mir etwas schleierhaft. Typo? Die letzte Zeile für retval klappt für den Code von hostif.c unter vmmon-only/linux nämlich auch.]

Nach Durchführung der Korrekturen ließen sich die VMware-Codes jedenfalls anstandslos für Kernel "4.4.9-31-default" kompilieren - und die nötigen Kernelmodule wurden fehlerfrei erzeugt. Meine zwei lokalen (non shared) virtuellen Maschinen für Windows-Installationen liefen damit bislang einwandfrei.

Ob es - wie in der Diskussion im VMware Community Forum angedeutet, Probleme mit "shared VMs" auf Servern gibt, habe ich nicht getestet. Auf Servern verwende ich KVM-Installaionen mit spice oder X2GO.

Viel Spaß denn mit Opensuse 42.3 auf dem Laptop!

Reaktivierung des Backups eines Windows-Gastes unter VMware Workstation

Es gibt eine ganze Reihe von Situationen, in denen man auf ein (komplettes) Backup einer unter VMware installierten Gastmaschine zurückgreifen möchte:

  • Updates/Upgrades: Oft genug verursachen ureigenste Updates des Betriebssystem-Herstellers oder aber bestimmter Programm-Suites erhebliche Probleme. Das gilt für Windows-Systeme in besonderem Maße. OK - es gibt die Wiederherstellungspunkte unter Windows selbst. Um die nutzen zu können, muss das System aber noch lauffähig sein.
  • Fehler von Benutzern mit Admin-Rechten: Wiederherstellungspunkte schützen nicht vor bestimmten gravierenden Fehlern von Anwendern mit hohen Berechtigungen auf dem VMware-Host wie auf der VMware-Gast-Maschine - echte Backups sind grundsätzlich unerlässlich.
  • Änderungen an der HW-Ausstattung der virtuellen Maschine: Für Performance-Tests möchte man ggf. mit der HW-Ausstattung der virtuellen Maschine experimentieren. HW-Änderungen sind oft auch im Zusammenhang mit VMware-Upgrades angebracht.
  • Pentests: Eine ganz eigene Klasse von Systemmanipulationen entsteht zudem im Zuge von Tests in einem Pentest-Labor: je nachdem, mit welchen Angriffsvektoren man sich da auseinandersetzt, kann das Ziel-System, also das VMware-Gastsystem, so in Mitleidenschaft gezogen werden, dass es danach schlicht nicht mehr funktionstüchtig ist.

Für all diese Situationen muss man vorausschauend planen. VMware bietet natürlich einen Snapshot-Mechanismus zur Fixierung des Zustands einer virtuellen Maschine an. Das schützt einen aber nicht vor Fehlern oder Ausfällen auf dem Virtualisierungshost selbst. Zudem muss man die Snapshot-Strategie konsequent anwenden; das erfordert in manchen Situationen einen erheblichen zusätzlichen Speicherplatz auf den Festplatten des Virtualisierungshosts und führt ggf. zudem systematisch zu Performance-Einbußen.

Meine Strategie ist grundsätzlich die, von wichtigen produktiven VMware-Installationen unter Linux zusätzlich zu Snapshots regelmäßig Kopien der gesamten Maschine anzufertigen und auf Partitionen externer Backup-Systemen zu verschieben. Mit Kopien meine ich echte Linux-Kopien der einer virtuellen Maschine im Linux-System zugeordneten Definitions- und virtuellen Hard-Disk-Dateien (cp -dpRv bzgl. der zu einer Maschine gehörigen .vcmx-, .vmxf-, .vmsd, .nvram-, .vmdk-Dateien). Von der vmx-Datei lege ich vorsorglich eine zweite Kopie (unter anderem Namen) an. Warum wird aus dem folgenden Text erkenntlich werden.

Nun ist ja bekannt, dass MS mit Windows vor allem Geld verdienen will. Intern überwacht das System daher Zustände und Veränderungen der (z.T. virtuellen) HW sowie anderer Parameter, die auf eine Veränderung der Systemumgebung hindeuten. Glaubt Windows bzw. Microsoft, dass solche Veränderungen einer Lizenzverletzung entsprechen, muss eine neue Aktivierung des Betriebssystems vorgenommen werden. Je nach Lizenzeinschränkungen kann das natürlich schiefgehen - im Besonderen, wenn Reaktivierungen in relativ kurzen Zeitabständen vorgenommen werden oder z.B. eine OEM-Lizenz plötzlich einer aus MS-Sicht neuen PC-Plattform zugeordnet wird.

Das Dumme ist, dass gerade Änderungen der HW-Ausstattung einer virtuellen Maschine (s. den obigen Punkt 3), die völlig legal erfolgen, aus Microsoft-Sicht böse sein können. Bestimmte Änderungen der (virtuellen) HW-Ausstattung werden von MS einfach mal so interpretiert, als habe man die zugrunde liegende PC-Plattform gewechselt. So ist ziemlich leicht, durch die Kombination zweier Änderungen einer virtuellen Maschine (Memory-Erweiterung + neue Netzwerkkarte oder CPU-Erweiterung + zusätzl. Netzwerkkarte) eine Neuaktivierung auszulösen. Das ist an sich schon ärgerlich. Ganz ekelhaft wird das Auslösen einer Windows-Reaktivierung aber beim Rückgriff auf ein Backup und dessen Inbetriebnahme. Im Besonderen dann, wenn das Problem der laufenden Windows-Maschine, das den Rückgriff auf ein Backup verursacht, durch ein Windows-Update selbst hervorgerufen wurde.

Falsche Reaktion auf Rückfragen von VMware

Ein Fehler, den man unter VMware schnell macht und der anschließend nicht mehr so einfach zu korrigieren ist, ist folgender:

Man hat eine Kopie aller Dateien einer virtuellen Windows-Maschine unter VMware erstellt und natürlich nicht weiter benutzt. Das laufende Windows-System ist aufgrund irgendwelcher Aktionen zerschossen. Man löscht die zugehörigen Dateien (ggf. auch aus Platzmangel). Man kopiert die Dateien des letzten Backups vom Backup-System zurück in eine Zielpartition des Linux-Systems. Man öffnet die virtuelle Maschine und startet sie. Dann kommt eine typische Frage von VMware mit etwa folgendem verkürzten Inhalt:

The virtual machine may have been moved or copied. ... In order to configure certain management and networking features VMware needs to know which. Did you move this virtual machine, or did you copy it? If you don't know, answer "I copied it".
Haben sie die Maschine kopiert oder verschoben? Im Zweifel soll man dann den Auswahlpunkt "Kopiert" anklicken.

Die Wahl "Kopiert" erscheint dann logisch, da das Backup ursprünglich ja mal als Kopie entstanden ist. Leider wird man dann nach dem Starten der Backup-Installation feststellen, dass eine Neuaktivierung von Windows erforderlich ist. Die ggf. fehlschlägt; man kann dann trotz Backups nicht mehr produktiv mit dem Gastsystem arbeiten.

In diese Falle bin ich selbst schon getappt. Zu beachten ist: Man hat in dem von mir beschriebenen Prozess nichts Illegales getan. Die Windows-Lizenz sieht das Anlegen von Backups vor. Man benutzt in dem beschriebenen Prozess die angelegte Backup-Kopie auch nicht parallel zum Original. (Das würde aus einem bestimmten Grund - s.u. - auch Zusatzmaßnahmen erfordern).

Ursache und Problemlösung

Im lokalen LAN müssen MAC-Adressen eindeutig sein, damit die Zuordnung von IP-Adresse zu MACs eindeutig wird und das ARP-Protokoll korrekt funktionieren kann. Wird eine Kopie einer virtuellen Maschine angelegt, so kann es natürlich sinnvoll sein, die MAC der virtuellen Maschine zu ändern, um bei einem Start des Originals und der Kopie zwei identische MAC-Adressen im Netz zu vermeiden. Antwortet man auf die obige Frage mit "Copied oder Kopiert", so passiert genau das: VMware ändert die Mac-Adressen der NICs der "kopierten" virtuellen Maschine. Aus Sicht von Windows hat das System dann eine oder gar mehrere neue Netzwerkkarten bekommen - im Spiel um eine Windows-Neuaktivierung entspricht dies einem sehr hoch bewerteten Kriterium.

VMWare vergibt zudem pro virtueller Maschine eine eindeutige UUID, die an die BIOS-Kennung (SMBIOS Descriptor) gebunden wird und somit auch von Windows erkennbar ist. Hierauf reagiert ein Konzern, dessen Erfolg auf Geldverdienen mit Lizenzen aufgebaut ist, natürlich allergisch. Beantwortet man also die obige (berechtigte) Frage von VMware mit "Kopiert", so wird die UUID von VMware geändert. Windows erkennt das und löst nach meiner Erfahrung in jedem Fall eine Reaktivierung aus, um eine Lizenzverletzung zu prüfen.

Leider begibt man sich durch beide Effekte als User schnell in Teufels (MS Lizenz-) Küche, wenn man auf die obige Frage von VMware falsch antwortet - selbst wenn man nicht Illegales tut und nur Backups reaktivieren will. Dies gilt im Besonderen dann, wenn man lediglich eine günstige OEM-Lizenz für sein Windows erworben hat, die ja relativ strikt eine bestimmte HW gebunden wird.

Will man solche Probleme vermeiden, gilt also:

Die richtige Antwort bei Reaktivierung eines Backups und Ersetzung der originalen virtuellen Maschine ist: "Moved" oder "Bewegt" - unabhängig davon, dass der Backup-Erstellung ein echter Kopierprozess zugrunde lag.

Selbst wenn diese Antwort mal falsch sein sollte: Alle UUID-Probleme, ja selbst das Netzwerkkarten-Problem, lassen sich bei Bedarf auch anders lösen. Eine bei MS vergeigte Lizenz durch Backup-Reaktivierung erfordert dagegen einen wesentlich höheren Aufwand an Zeit und Nerven.

Eine weitere Regel ist: Werft auch bei einer zerschossenen Windows-Maschine die zugehörige vmx-Definitionsdatei nicht sofort ins digitale Nirwana. Mit ihrer Hilfe kann man ggf. noch etwas retten, wenn die Aktivierung der Backup-Kopie bei Microsoft fehlschlagen sollte.

Manuelle UUID-Einstellungen und manuelle Vorgaben für Kopien

Der Vollständigkeit halber möchte ich darauf hinweisen, dass das Verhalten von VMware bzgl. der UUID-Änderung durch Anweisungen in der Definitionsdatei einer virtuellen Maschine beeinflusst werden kann. Siehe hierzu einige der unten angegebenen Links.

Auch die MAC-Einstellungen sind in der vmx-Datei natürlich zugänglich für evtl. notwendige Änderungen oder Rückschreibungen auf die ursprünglichen Werte.

Links

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1541
https://www.vmware.com/support/ws5/doc/ws_move_uuid_moving_virtual_machines.html
https://pubs.vmware.com/workstation-12/index.jsp#com.vmware.ws.using.doc/GUID-533B2C4F-7BD5-41EB-8392-2B9FE687AE50.html
https://pubs.vmware.com/workstation-12/index.jsp?topic=%2Fcom.vmware.ws.using.doc%2FGUID-533B2C4F-7BD5-41EB-8392-2B9FE687AE50.html
https://jojitsoriano.wordpress.com/2010/09/03/avoiding-activation-when-movingcopying-a-windows-7-vmware-image/

VMware Workstation WS 11 unter Opensuse Leap 42.1

Habe heute ein Upgrade eines Opensuse 13.1-Systems auf Opensuse Leap 42.1 durchgeführt. Das ging - bis auf einige typische OS 42.1-Probleme, die ich bereits an anderer Stelle in diesem Blog beschrieben habe, ganz gut.

Gestolpert bin ich dann allerdings über ein Problem mit der VMware-Workstation. Die auf dem fraglichen System installierte Version war WS 11.1.0.

Da sich der Kernel gegenüber der Version von 13.1 inzwischen natürlich massiv verändert hatte (aktuelle Leap42.1-Kernelversion 4.1.27), führte der Versuch VMware WS zu starten, zu einer automatisch eingeleiteten Neu-Kompilation der wichtigsten VMware-Module. Dieser Kompilationsversuch scheitert aber leider an dem vmnet-Modul; nachfolgend ein Auszug aus der Log-Datei:

2016-09-26T14:13:52.987+02:00| vthread-4| I120: Successfully extracted the vmnet source.
2016-09-26T14:13:52.987+02:00| vthread-4| I120: Building module with command "/usr/bin/make -j8 -C /tmp/modconfig-jZLoM6/vmnet-only auto-build HEADER_DIR=/lib/modules/4.1.31-30-default/build/include CC=/usr/bin/gcc IS_GCC_3=no"
2016-09-26T14:13:54.615+02:00| vthread-4| W110: Failed to build vmnet. Failed to execute the build command.
....
2016-09-26T14:14:12.914+02:00| vthread-4| I120: Read 17587 symbol versions
2016-09-26T14:14:12.914+02:00| vthread-4| I120: Invoking modinfo on "vmmon".
2016-09-26T14:14:12.919+02:00| vthread-4| I120: "/sbin/modinfo" exited with status 0.
2016-09-26T14:14:12.919+02:00| vthread-4| I120: Invoking modinfo on "vmnet".
2016-09-26T14:14:12.924+02:00| vthread-4| I120: "/sbin/modinfo" exited with status 256.
2016-09-26T14:14:13.334+02:00| vthread-4| I120: Setting destination path for vmnet to "/lib/modules/4.1.31-30-default/misc/vmnet.ko".
2016-09-26T14:14:13.334+02:00| vthread-4| I120: Extracting the vmnet source from "/usr/lib/vmware/modules/source/vmnet.tar".
2016-09-26T14:14:13.344+02:00| vthread-4| I120: Successfully extracted the vmnet source.
2016-09-26T14:14:13.344+02:00| vthread-4| I120: Building module with command "/usr/bin/make -j8 -C /tmp/modconfig-sDUVWe/vmnet-only auto-build HEADER_DIR=/lib/modules/4.1.31-30-default/build/include CC=/usr/bin/gcc IS_GCC_3=no"
2016-09-26T14:14:14.951+02:00| vthread-4| W110: Failed to build vmnet. Failed to execute the build command.

Dieses Problem lässt sich beheben, ohne gleich für teures Geld auf die WS 12 upgraden zu müssen. Es handelt sich nämlich um einen Fehler, der in einer späteren Version behoben wurde.

Kurz gesagt: Version 11.1.4 der WS runterladen => Installieren => VM-Ware WS auch unter Opensuse Leap 42.1 weiter betreiben !