Upgrade to Opensuse Leap 15.2 with old CPU – get VMware 12.5.9 running

Readers of this blog know that we have a PC with a relative old CPU - an i7 950. I have no intention to replace it at the moment. Although it still is a very capable CPU VMware stopped support for it with their Workstation 14.0. The last version which worked for this old CPU was Vmware WS 12.5.9, which fortunately was one of the first versions that supported Windows 10 as a guest OS.

Whenever I upgraded Opensuse Leap on the named PC during the last years I had to make use of the work of a nice guy named Michal Kubeček, who generously publishes patches for older VMware WS versions on GitHub.
See: https://github.com/mkubecek/vmware-host-modules

In previous articles I have already referred to one of his patches which worked well with Opensuse Leap 15.0 and 15.1 - and kernel 4.x. See:
VMware WS 12.5.9 on Opensuse Leap 15.1

Now, with Leap 15.2 we eventually got a kernel version 5.3. Therefore, you have to download a different file from the GitHub repository. Look out there for branch "tmp/workstation-12.5.9-k5.10" and clone the code there or download
wget https://github.com/mkubecek/vmware-host-modules/archive/refs/heads/tmp/workstation-12.5.9-k5.10.zip
or
wget https://github.com/mkubecek/vmware-host-modules/archive/tmp/workstation-12.5.9-k5.10.tar.gz

After an expansion the recipe given in the previous article named above can be applied:

wget https://github.com/mkubecek/vmware-host-modules/archive/tmp/workstation-12.5.9-k5.10.tar.gz
tar -xzf workstation-12.5.9-k5.10.tar.gz
cd vmware-host-modules-workstation-12.5.9-k5.10
make
make install

and (if its the first time you applied such a patch)

cd /usr/lib/vmware/lib/libfontconfig.so.1
mv libfontconfig.so.1 libfontconfig.so.1.old
ln -s /usr/lib64/libfontconfig.so.1

Worked without problems on my system. And a Win10 installation is happily running on the old PC.

Thank you very much, Michal Kubeček.

VMware Workstation – Virtual Ethernet failed – sometimes for good!

I use VMware Workstation as a hypervisor for hosting a few MS Windows guests, which I need in customer projects. As I do not trust Windows systems I sometimes place such guests in different virtual and isolated host-only networks on my workstation or a dedicated server. On other systems I run virtualized Linux server systems for production and tests with the help of KVM/QEMU, LXC and libvirt. Some time ago I learned the hard way that I have to keep track of the different "local" virtual networks more thoroughly. As the VMware side was affected by a misconfiguration in a rather peculiar way I thought this experience might be interesting for others, too.

Host interface to VMware virtual network sometimes not available?

The whole thing coincided with an upgrade of one of my Opensuse workstations. I am always a bit nervous whether and how such an upgrade may impact the VMware WS installation. Quite often I experienced problems with the automatic compilation in the past. In addition the start of some modules lead to secondary errors. However, at a first test VMware WS 14 compiled without problems on a system with Opensuse Leap 15. No wonder, I thought, as the kernel version 4.12 of Leap15 is relatively old.

Then I had to set up a Windows guest. I gave it an IP address within a virtual VMware host-only network, which covered an IPv4 address range of a class C network. VMware uses a kind of virtual bridge to support such a network; normally one associates a virtual network device on the host with it, to which you can assign a certain IP address in the net's address ange. For a C-net VMware uses yyy.yyy.yyy.1 as a default on the host's interface (with yyy.yyy.yyy defining the C-network). In my case the device on the host was named "vmnet6". In the beginning this virtual interface also worked as expected.

However, during the following days I noticed trouble with "vmnet6". In a normal host configuration the VMware WS initialization script ("/etc/init.d/vmware") is started as a LSB service by systemd. The script loads VMware modules and configures the defined virtual networks. Unfortunately, relatively often, my "vmnet6" interface did not become directly available after the start of the Linux host. Some experiments showed however that I could circumvent this problem by some "dubious" action:

I had to enter the "Virtual Network Editor" with root rights and save the already existing virtual network again. Then ifconfig or the ip command enlisted interface "vmnet6" - which also seemed to work normally.

You get a strange feeling when you are forced to remedy something as root .... However, I ignored this problem, which I could not solve directly, for a while. I also noticed that the problem did not occur all the time. This should have rang a bell ... but I was too stupid. Until, yesterday, when I needed to set up another special MS WIN guest in the same address range.

Virtual Ethernet failed

In addition I upgraded to VMware WS Version 14.1.3. The (automatic) compilation of the VMware WS modules on Opensuse Leap 15 again worked without major problems. But, when I manually (re-) started the VMware modules via "/etc/init.d/vmware restart" I saw an error message:

"Virtual Ethernet failed".

Such a message makes you nervous because you assume some real big problem with the VMware modules. However, starting some of my VMware guests (not the ones linked to vmnet6) proved that these guests operated flawlessly and could communicate via their and the hosts network devices. But my "vmnet6" did not appear in the output of "ip a s".

The problem "Virtual Ethernet failed" is reported in some Internet articles; however without a real solution. See e.g. https://ubuntuforums.org/showthread.php?t=1592977; https://www.linuxquestions.org/questions/slackware-14/vmware-workstation-unable-to-start-services-4175547448/; https://communities.vmware.com/thread/264235.

Now, I seriously began to wonder whether and how this problem was related to the already known problem with my virtual device "vmnet6". Some tests quickly showed that the error message disappeared when I eliminated the host-only network related to "vmnet6". Then I tried a new host-only test network with a device "vmnet7" and a different IP range. Also then the "virtual Ethernet" started flawlessly. So, what was wrong with "vmnet6" and/or its IP range? Some residual garbage from old installations? A search for configuration files gave me no better ideas.

vnetlib-log

After a minute I thought: Maybe VMware is right. A look into the log-file "/var/log/vnetlib" revealed:

Oct 14 14:22:49 VNL_Load - LOG_ERR logged
Oct 14 14:22:49 VNL_Load - LOG_WRN logged
Oct 14 14:22:49 VNL_Load - LOG_OK logged
Oct 14 14:22:49 VNL_Load - Successfully initialized Vnetlib
...
Oct 14 14:22:49 VNL_StartService - Started "Bridge" service for vnet: vmnet0
Oct 14 14:22:49 VNLPingAndCheckSubnet - Return value of vmware-ping: 0
...
Oct 14 14:22:50 VNL_CheckSubnetAvailability - Subnet: xxx.xxx.xxx.xxx on vnet: vmnet2 is available
...
Oct 14 14:22:49 VNL_CheckSubnetAvailability - Subnet: yyy.yyy.yyy.yyy on vnet: vmnet6 is not available
Subnet on vmnet6 is no longer available for usage, please run the network editor to reconfigure different subnet
Oct 14 14:22:50 VNL_CheckSubnetAvailability - Subnet: xxx.xxx.xxx.xxx on vnet: vmnet7 is available
Oct 14 14:22:50 VNL_CheckSubnetAvailability - Subnet: xxx.xxx.xxx.xxx on vnet: vmnet8 is available
.....

(I have replaced real addresses by xxx and yyy.) So, obviously VMware at startup performs a kind of ping check beyond the locally defined virtual devices and networks. Interesting! Why do they ping?

The answer is trivial: When you set up the (virtual) internal bridge for the host-only network you may want to guarantee that the IP-address for the respective host device ("vmnet6") does not exist anywhere else in the reachable network - especially as the host's interface of a host-only network may be used for a host controlled routing (and NAT) of the otherwise isolated VMware guests to the outside world.

Address overlap

And this resolved my problem: A manual ping for the address of the planned host's interface address yyy.yyy.yyy.1 indeed gave me a result. I located the source on another server, where I sometimes perform tests of different virtual network configurations with KVM guests, LXC containers and libvirt. Unfortunately, I had not disabled all of my test networks after my last tests. Due to default DHCP-settings a virtual interface with address yyy.yyy.yyy.1 got established on the test server whenever it was booted. This also explained the finding that the VMware WS problem did not occur always - it only happened when the test server was active in my physical LAN!

Then I actually remembered that I had had a similar problem once in 2016, whilst experimenting with QEMU/VMware-bridge-coupling. (See: Opensuse/Linux – KVM, VMware WS – virtuelle Brücken zwischen den Welten). So, I should have known better and planned my "local" virtual experiments a bit more carefully to avoid address overlaps with other potential virtual networks on different hosts in the LAN.

Stupid me ... The VMware WS startup script was absolutely right to not establish a second address of that kind on my workstation! This lead to the error message "Virtual ethernet failed" - which in my opinion should include a bit more detailed information or a hint to a log-file. But the fault clearly was on my side: One should not think in terms of a local host environment when using VMware WS for virtual networks, but consider the global network configuration.

Still, the whole VMware handling of a possible IP address overlap left me a bit puzzled :

Why can you by saving the questionable virtual network again establish a host interface despite the fact that another interface with the same address is running somewhere in the network? OK, you are root when you do it - but why is no warning given at this point? (VMware could do a ping check there, too .... )

A second question also worried me: Why did the existence of two devices with the same IP-address did not lead to more chaos in the network? One reason probably was that I had allowed pinging but no general TCP-transport to the virtual device on the test server. And explicit routes were otherwise defined properly on the different hosts. However, I could bet on some problems on the ARP-level when the test server was up and running. Anyway - such a basic misconfiguration in a a network may lead to security holes, too, and should, of course, be avoided.

A third question that came up for a second was: How do you avoid overlaps in case one wants to assign KVM/QEMU-guests and VMware guests IP addresses within the same network address space on one and the same virtualization host? Such a scenario is not at all as far fetched as it may seem at first sight. One reason for such a configuration could be the EU GDPR (DSGVO):

If you need to guarantee a customer confidentiality and are nevertheless forced to use a standard MS Windows client, you have a problem as MS may in an uncontrollable way transfer data to their own servers (outside the EU). Just read the license and maintenance agreements you sign with the operation of a standard Win 10 client! Therefore, you may want to isolate such clients drastically and only allow for communication with certain IP-addresses on the Internet (and NOT with MS servers). You may allow communication with some (virtualized) Linux machines in the same sub-network and one of them may serve as a gateway and perimeter firewall with strict filters. You can build up such scenarios by coupling a QEMU-virtual bridge to a VMware virtual bridge. At the same time, however, you need full control over the DHCP-systems on both sides (besides a bit of scripting) to avoid address overlaps. But this is actually easy: the DHCP-control files on the VMware side are found under the directory "/etc/vmware/vmnetX/dhcpd", with "X" standing for a virtual VMware interface number. On the QEMU side you find the files at "/etc/libvirt/qemu/networks". There you can control your IP assignments (or even no assignments for some special interfaces). Ok, but this is the beginning of another story.

Conclusion

Never think "local" or host based when working with virtual networks! Always include local virtual test networks in your documentation of your global network landscape! An do not always just accept the standard address assignment for host interfaces to virtual networks without thinking.

Upgrade auf Opensuse Leap 15.0 – Probleme mit Nvidia-Treiber aus dem Repository und mit VMware WS 12.5.9

Opensuse Leap 15.0 ist nun schon eine Weile auf dem Markt. Zeit, von Leap 42.3 umzusteigen. Also ein Upgrade durchführen. Geht das problemfrei?

Upgrade von PCs/Workstations

Ich habe Upgrades inzwischen an einem Laptop und auf zwei Linux-Workstations durchgeführt. Ich spreche nachfolgend also nicht über echte Opensuse-basierte Server-Systeme. Die gute Nachricht für Leute, die ihre PCs / Workstations bislang unter Opensuse Leap 42.3 mit ext4 und LVM betrieben haben, ist:

Man kann ohne allzu große Schwierigkeiten auf Leap 15.0 upgraden. Das gilt auch, wenn man eine Reihe von Zusatz-Repositories für bestimmte SW eingesetzt hat (in meinem Fall für Produkte aus den Packman-, Security-, Network-, Forensic-, PHP, Java-, .... -Repositories, die Opensuse eben so anbietet).

Einschränkungen:
Da Leap 15.0 bzgl. BTRFS ein paar neue Features mitbringt, traue ich mich nicht, dieses Statement so auch für Systeme zu machen, bei denen das Root-Filesystem auf BtrFS aufsetzt. Auch Laptops mit Optimus-Systemen habe ich noch nicht umgestellt.

Vorgehensweise für das Upgrade
Man folgt für das Upgrade am besten der unter
https://kamarada.github.io/en/2017/08/03/how-to-upgrade-from-opensuse-leap-422-to-423/
beschriebenen grundsätzlichen Schrittfolge. Der genannte Artikel beschreibt zwar den Wechsel von Leap 42.2. auf Leap 42.3. Die angegebenen Schritte lassen sich aber ganz analog auch auf ein Upgrade auf von Leap 42.3 auf Leap 15.0 anwenden. Natürlich muss man "Leap 42.2" bzw. "Leap 42.3" in den Vorgaben sinngemäß durch "Leap 42.3" bzw. "Leap 15.0" ersetzen.

Das Upgrade von KDE/Gnome und SSDM/GDM3 funktioniert. Auch Apache2- und MySQL-Dienste werden auf den neuesten Stand gebracht und laufen dann mit den alten Konfigurationen weiter. KVM/Gäste ließen sich in der erneuerten KVM/QEMU/libvirt/spice-Umgebung problemfrei starten. Nach dem Upgrade des System-Kerns bindet man die benötigten zusätzlichen Repositories ein und zieht seine Spezialanwendungen und Multimedia-Anwendungen nach. Bzgl. Multimedia primär über Packman; nur im Einzelfall greife ich auf Pakete anderer Multimedia-Repos zu. Unter Leap 15 unterstützt auch eine Implementierung von JAVA 10 etwa Eclipse Photon bei entsprechender Konfiguration sehr stabil. Das Weiterentwickeln von SW mit Hilfe von Eclipse ist also gesichert. Einzig manche Default GTK3-Styles muss man ändern, um sowohl LibreOffice 6 als auch Eclipse Photon mit Dark Scheme ohne Augenprobleme nutzen zu können (s. hierzu frühere Artiekl im Blog).

Natürlich gibt es im Einzelfall aber doch ein paar knifflige Hürden. Nachfolgend zwei, die mir den Umstieg erschwert haben:

Nvidia-Probleme

Für ein KDE-basiertes System "mytux1", auf dem ich schon bislang die Nvidia-Treiber aus dem Opensuse-Nvidia-Repository genutzt hatte, funktionierte der Wechsel auf Leap 15.0 anstandslos. Man landet bei der Vorgehensweise des oben erwähnten Artikels zwar zunächst (erwartungsgemäß) im Konsolen-Modus. Dort muss man über die ASCII-Variante von YaST Oberfläche das Nvidia-Repository
https://download.nvidia.com/opensuse/leap/15.0
zum YaST-Software-Management hinzufügen und anschließend die passenden Treiber für sein Nvidia-Kartenmodell installieren. SDDM und KDE5 Plasma kamen nach einem Reboot dieses Systems auf Anhieb hoch.

Schwierigkeiten bereitete aber ein anderes KDE-basiertes System "mytux2", für das ich seit Jahren aktuelle proprietäre Treiberversionen von der Nvidia Web-Site heruntergeladen und manuell über den Nvidia-Installer installiert hatte. Auf diesem System führte der Versuch einer ersten Treiberinstallation aus den Opensuse-Nvidia-Repositories ins Nirwana:

Beim Hochfahren flackerte zunächst das Konsolen-Terminal mit dem angezeigten Prompt; in diesem Modus sind kontrollierte Eingaben kaum möglich. Das ist mir übrigens nicht zum ersten Mal bei Upgrades passiert. Zur Vorsorge ist es sehr nützlich, vor dem Upgrade den SSHD-Service zu aktivieren (systemctl enable ....). Man kann sich dann beim Hochfahren nach dem Upgrade wenigstens von anderen Systemen aus einloggen und ein "init 3" absetzen, damit sich die Anzeige "beruhigt".

Nun hat man zwei Möglichkeiten: Download einer aktuellen Treiber-Version von der Nvidia-Website und manuelle Installation. Oder aber: Zuschalten des Nvidia-Repositories und Installation der Treiber über RPM-Pakete und YaST. Ich habe zuerst Letzteres versucht. Systemd initiierte dann nach einem Restart auch den Wechsel zum graphischen "Target" und versuchte erkennbar X und SDDM zu starten; das Ganze endete aber in einem schwarzen Schirm mit Mauszeiger. Und nicht mit der Anzeige des SDDM-Login-Schirm ...

In einigen Internet-Beiträgen zu ähnlichen Problemen wird empfohlen, den User "sddm", unter dem der Login- und Display-Manager SDDM für KDE Plasma-Nutzer ausgeführt wird, zu einem Mitglied der Gruppe "video" zu machen. Das half in meinem Fall aber gar nichts.

Was war da faul?

Zunächst besorgte ich mir zum Vergleich den aktuellen Treiber manuell von der Nvidia-Website; in der gleichen Version wie im Nvidia-Repository hinterlegt. Und siehe da: die manuelle Installation (inkl. Kompilation etc.) über den Nvidia-Installer (also das "run"-Skript ) funktionierte! Allerdings kam eine Warnung, dass die vorhandene "libglvnd"-Installation nicht vollständig sei. Man wird dann vom Nvidia-Installer gefragt, ob er die Installation aus eigenen Ressourcen korrigieren solle. Ich habe dem zugestimmt. Danach kamen SDDM und KDE Plasma anstandslos hoch. Durchatmen: wenigstens die manuelle Installation führt zum Erfolg. Es gibt also kein fundamentales Problem zwischen Leap 15 und den Nvidia-Treibern. Was aber, wenn man aus bestimmten Gründen zu den Opensuse-Nvidia-Repos wechseln will?

Eine komplette Deinstallation des Nvidia-Treibers über das zugehörige Run-File per

bash /extras/Updates/nvidia/NVIDIA-Linux-x86_64-390.87.run --uninstall

und eine anschließende Installation des gleichen Treibers per Opensuse-Nvidia-Repo führte leider wieder ins Nirwana.

Auffällig war bei der manuellen Deinstallation allerdings eine Meldung zu nicht ordnungsgemäß herstellbaren Links im Verzeichnis "/usr/lib64". Dort liegen bekanntermaßen *.so-Libraries. Ein genaues Studium der im Zuge der verschiedenen Installationen angelegten Links in diesem Verzeichnis brachte dann die Lösung:

Nach einer funktionierenden manuellen Installation des Treibers von der Nvidia-Website gab es dort folgende relevante Einträge :

mytux2:/usr/lib64 # la | grep libGL
-rw-r--r--   1 root root       656 Sep 21 18:46 libGL.la
lrwxrwxrwx   1 root root        10 Sep 21 18:46 libGL.so -> libGL.so.1
lrwxrwxrwx   1 root root        14 Sep 21 18:46 libGL.so.1 -> libGL.so.1.7.0
-rwxr-xr-x   1 root root    665720 Sep 21 18:45 libGL.so.1.7.0
....

Das Vergleichssystem "mytux1" zeigte hingegen folgende Konstellation:

mytux1:/usr/lib64 # la | grep libGL
lrwxrwxrwx   1 root root        14 Sep  4 21:40 libGL.so -> libGL.so.1.0.0
lrwxrwxrwx   1 root root        14 Sep  4 21:40 libGL.so.1 -> libGL.so.1.0.0
-rwxr-xr-x   1 root root    588160 Apr 25 03:09 libGL.so.1.0.0

Andere Versionsnummern, aber eine ähnliche Verlinkung.

Nach dem manuellen Uninstall per "bash /extras/Updates/nvidia/NVIDIA-Linux-x86_64-390.87.run --uninstall " auf "mytux2"
und einem Installieren der Treiberdateien aus den Opensuse-Nvidia-Repositories für Leap 15.0 ergab sich hingegen folgendes Bild:

mytux2:/usr/lib64 # la | grep libGL       
lrwxrwxrwx   1 root root        14 Sep 21 19:52 libGL.so -> libGL.so.1.0.0
lrwxrwxrwx   1 root root        14 Sep 21 19:52 libGL.so.1 -> libGL.so.1.2.0
-rwxr-xr-x   1 root root    588160 Apr 25 03:09 libGL.so.1.0.0
lrwxrwxrwx   1 root root        14 Sep 21 19:52 libGL.so.1.2 -> libGL.so.1.2.0
-rwxr-xr-x   1 root root    430760 Nov 21  2016 libGL.so.1.2.0
...  

Hier war zwischenzeitlich offenbar etwas Altes aus dem Jahre 2016 restauriert worden! Woher der Nvidia-Uninstaller das auch immer genommen haben mag... Dass der Nvidia Installer/Uninstaller damit zu tun hatte, ergab sich aus der Tatsache, dass die Datei "libGL.so.1.2.0" sich keinem RPM-Repository zuordnen ließ, die libGL.so.1.0.0 aber schon :

mytux2:/usr/lib64 # rpm -qf libGL.so.1.0.0
libglvnd-1.0.0-lp150.1.1.x86_64

Wer immer da wann was im "libGL/libglvnd"-Umfeld verbrochen hatte; dieser Schaden ließ sich beheben. Offenbar ist für die Repository basierten Treiber nur die "libGL.so.1.0.0" maßgeblich. Ich habe daher eine Umsetzung der Links vorgenommen und die "libGL.so.1.2.0" gelöscht. (Auch die manuelle Treiberinstallation nutzt diese Bibliothek ja nicht ...; s.o.).

mytux:/usr/lib64 # la | grep libGL
lrwxrwxrwx   1 root root        14 Sep 21 19:52 libGL.so -> libGL.so.1.0.0
lrwxrwxrwx   1 root root        14 Sep 21 23:27 libGL.so.1 -> libGL.so.1.0.0
-rwxr-xr-x   1 root root    588160 Apr 25 03:09 libGL.so.1.0.0
lrwxrwxrwx   1 root root        14 Sep 21 23:27 libGL.so.1.2 -> libGL.so.1.0.0

Die Dateien aus dem Opensuse-Nvidia-Repository habe ich dann zur Sicherheit nochmal überinstalliert. Und siehe da, danach lief alles. Den Link "libGL.so.1.2" konnte ich schließlich auch ohne Schaden wegschmeißen.

Merke: Eine Historie mit Wechseln von Nvidia-Treiber-Installationen aus dem Opensuse-Repository und manuellen Installationen per Nvidia-Installer-Daten bleibt nicht immer verwerfungsfrei. Ein Blick in die Links unter "/usr/lib64" ist hilfreich.

Problem mit VMware WS 12.5.9 unter Leap 15.0

Auf einem meiner Systeme läuft eine relativ aktuelle VMware WS 14.1.1-Umgebung. Die überlebte das Upgrade auf Leap 15.0 anstandslos. Die Module wurden im Hintergrund neu kompiliert und erfolgreich gestartet.

Auf einem anderen System lief aber die WS 12.5.9. Die ließ sich zunächst nicht dazu bewegen zu starten. Die Module für den "Virtual Machine Monitor" wie das "Virtual Network" konnten nicht erfolgreich kompiliert werden. Hier hatten findige Menschen aber dankenswerterweise schon vorgearbeitet; das Problem ist bekannt und gelöst. Die notwendigen Schritte, die auch auf meinem System zum Erfolg führten findet ihr hier

https://communities.vmware.com/message/2777306#2777306

Addendum, 25.03.2020: The steps described in the referenced community article work on Leap 15.1, too.

Viel Spaß dann mit Opensuse Leap 15 ! ZU Leap 15 und Optimus bald mehr, wenn ich Zeit finde ...