Google kündigt die Verfügbarkeit eine Command Line Interfaces (CLI) für sein Sprachmodell Gemini an, das für die allermeisten Anwender kostenlos ist: Es erlaubt 60 Modellanfragen pro Minute und 1…
Wenn Sie meinen vorigen Blogbeitrag über Hetzner-Cloud-Benchmarks gelesen haben, ist Ihnen vielleicht aufgefallen, dass ich Alma Linux 10 in einer Hetzner-Cloud-Instanz ausgeführt habe, um dort Geekbench-Tests auszuführen. Das war nicht so einfach: Hetzner bietet Alma Linux 10 noch nicht als Installations-Image an.
Also habe ich eine neue Instanz zuerst mit Alma Linux 9 eingerichtet und danach mit Elevate ein Update auf Version 10 durchgeführt. Das ist erstaunlich unkompliziert gelungen, obwohl Version-10-Updates eigentlich noch im Beta-Test sind.
RHEL und alle Klone durchlaufen über reguläre Updates alle Minor-Releases. Wenn Sie also Alma Linux 9.0 installiert haben, erhalten Sie durch die regelmäßige Installation von Updates nach und nach die Versionen 9.1, 9.2 usw. Ein Update auf die nächste Major-Version ist aber nicht vorgesehen.
Mit LEAPP hat Red Hat ein Framework geschaffen, um Major-Version-Updates für RHEL durchzuführen. LEAPP wurde sehr allgemeingültig konzipiert und kümmert sich um Pre-Upgrade-Kontrollen, Paketabhängigkeiten, den Workflow zwischen verschiedenen Stadien des Upgrades usw.
Elevate ist eine Community-Erweiterung zu LEAPP, die über das eigentliche Upgrade hinaus in manchen Fällen auch einen Wechsel der Paketquellen zwischen Alma Linux, CentOS, Oracle Linux und RockyLinux durchführen kann. Sie können mit Elevate beispielsweise zuerst von CentOS 7 zu RockyLinux 8 migrieren und dann weiter zu Rocky Linux 9 upgraden.
Bevor Sie Elevate anwenden, müssen Sie ein vollständiges Backup durchführen und Ihren Rechner bzw. Ihre virtuelle Maschine neu starten:
Anmelden
dnf update
reboot
Danach richten Sie eine Paketquelle für Elevate ein und installieren das für Sie relevante Upgrade-Modul (für das Beispiel in diesem Artikel mit der Zieldistribution Alma Linux also leapp-data-almalinux).
dnf install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm
# für AlmaLinux
dnf install leapp-upgrade leapp-data-almalinux
# alternativ für Rocky Linux (etc.)
dnf install leapp-upgrade leapp-data-rocky
Als nächstes folgt ein Test, ob das gewünschte Upgrade (plus gegebenenfalls eine Migration zu einer anderen Distribution, hier nicht relevant) überhaupt möglich ist:
leapp preupgrade
leapp preupgrade erzeugt zwei Dateien: Einen umfassenden Bericht, der alle möglichen Probleme aufzählt, und eine answer-Datei, in die Sie gegebenenfalls Optionen eintragen müssen (z.B. mit leapp answer --section check_vdo.confirm=True). In meinem Fall — Upgrade einer Minimalinstallation von Alma Linux 9 auf 10, hat leapp preupgrade auf die folgenden Probleme hingewiesen, aber keine answer-Einträge verlangt.
/etc/sysconfig/network-scriptshc-utils)cat /var/log/leapp/leapp-report.txt
Risk Factor: high (inhibitor)
Title: Legacy network configuration found
Summary: Network configuration files in legacy "ifcfg" format are present ...
- /etc/sysconfig/network-scripts/ifcfg-eth0
Related links:
- How to migrate the connection from ifcfg to NetworkManager keyfile plugin?:
https://access.redhat.com/solutions/7083803
- nmcli(1) manual, describes "connection migrate" sub-command.:
https://networkmanager.dev/docs/api/latest/nmcli.html
...
Remediation: [hint] Convert the configuration into NetworkManager native "keyfile" format.
----------------------------------------
Risk Factor: high
Title: Detected custom leapp actors or files.
Summary: We have detected installed custom actors or files on the system.
These can be provided e.g. by third party vendors ... This is allowed
and appreciated. However Red Hat is not responsible for any issues caused
by these custom leapp actors ...
The list of custom leapp actors and files:
- /usr/share/leapp-repository/repositories/system_upgrade/\
common/files/distro/almalinux/rpm-gpg/10/RPM-GPG-KEY-AlmaLinux-10
- /usr/share/leapp-repository/repositories/system_upgrade/\
common/files/rpm-gpg/10/RPM-GPG-KEY-AlmaLinux-10
...
Den vollständigen Report können Sie sich hier durchlesen.
Wirklich kritisch war aus meiner Sicht nur die Netzwerkkonfiguration; die restlichen Hinweise und Empfehlungen habe ich ignoriert. Das Paket hc-utils (Hetzner Cloud Utilities) ist nur für Funktionen relevant, die in meinem Fall ohnedies nicht genutzt werden (siehe hier).
Auch die veraltete Netzwerkkonfiguration stammt vom Hetzner-Image für Alma Linux 9. Eine Umstellung auf eine *.nmconnection-Datei für den NetworkManager gelingt erstaunlich unkompliziert mit einem einzigen Kommando:
nmcli connection migrate /etc/sysconfig/network-scripts/ifcfg-eth0
Mit einem weiteren Reboot habe ich sichergestellt, dass die Umstellung auch funktioniert.
leapp upgrade initiiert nun das Upgrade auf Alma Linux 10. Dabei werden seitenweise Logging-Ausgaben produziert (siehe den kompletten Output mit ca. 3150 Zeilen):
leapp upgrade
==> Processing phase `configuration_phase` ...
==> Processing phase `FactsCollection` ...
...
==> Processing phase `TargetTransactionFactsCollection`
Create custom repofile containing information about
repositories found in target OS installation ISO, if used.
Initializes a directory to be populated as a minimal environment
to run binaries from the target system.
AlmaLinux 10.0 - BaseOS 5.9 MB/s | 2.8 MB 00:00
AlmaLinux 10.0 - AppStream 11 MB/s | 5.6 MB 00:00
AlmaLinux 10.0 - CRB 5.0 MB/s | 2.2 MB 00:00
AlmaLinux 10.0 - HighAvailability 161 kB/s | 69 kB 00:00
AlmaLinux 10.0 - Extras 28 kB/s | 12 kB 00:00
AlmaLinux 10.0 - SAP 8.3 kB/s | 3.5 kB 00:00
AlmaLinux 10.0 - SAPHANA 35 kB/s | 15 kB 00:00
AlmaLinux 10.0 - RT 2.8 MB/s | 1.1 MB 00:00
AlmaLinux 10.0 - NFV 2.8 MB/s | 1.1 MB 00:00
Dependencies resolved.
...
Transaction Summary: Install 153 Packages
...
Complete!
==> Processing phase `TargetTransactionCheck`
...
Transaction Summary
Install 63 Packages
Upgrade 389 Packages
Remove 18 Packages
Downgrade 3 Packages
Transaction test succeeded.
Complete!
====> add_upgrade_boot_entry
Add new boot entry for Leapp provided initramfs.
A reboot is required to continue. Please reboot your system.
Debug output written to /var/log/leapp/leapp-upgrade.log
============================================================
REPORT OVERVIEW
============================================================
HIGH and MEDIUM severity reports:
1. Packages not signed by Red Hat found on the system
2. Detected custom leapp actors or files.
3. Berkeley DB (libdb) has been detected on your system
Reports summary:
Errors: 0
Inhibitors: 0
HIGH severity reports: 2
MEDIUM severity reports: 1
LOW severity reports: 2
INFO severity reports: 1
Before continuing, review the full report below for details about discovered
problems and possible remediation instructions:
A report has been generated at /var/log/leapp/leapp-report.txt
A report has been generated at /var/log/leapp/leapp-report.json
============================================================
END OF REPORT OVERVIEW
============================================================
Answerfile has been generated at /var/log/leapp/answerfile
Reboot the system to continue with the upgrade. This might take a while
depending on the system configuration.
Make sure you have console access to view the actual upgrade process.
Jetzt wird es unheimlich: Mit reboot starten Sie die nächste Phase des Upgrade-Prozesses, der im Blindflug erfolgt. Der Rechner bzw. die virtuelle Maschine wird während dieser Phase noch einmal neu gestartet. Wenn Sie nicht vor dem Rechner sitzen, sehen Sie weder, was passiert, noch haben Sie über eine SSH-Verbindung die Möglichkeit, einzugreifen.
reboot
Wenn alles gut geht, können Sie sich nach ein paar Minuten wieder einloggen. Bei mir hat es funktioniert:
ssh root@1.2.3.4
cat /etc/os-release
NAME="AlmaLinux"
VERSION="10.0 (Purple Lion)"
ID="almalinux"
ID_LIKE="rhel centos fedora"
VERSION_ID="10.0"
PLATFORM_ID="platform:el10"
PRETTY_NAME="AlmaLinux 10.0 (Purple Lion)"
ANSI_COLOR="0;34"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:almalinux:almalinux:10::baseos"
HOME_URL="https://almalinux.org/"
DOCUMENTATION_URL="https://wiki.almalinux.org/"
VENDOR_NAME="AlmaLinux"
VENDOR_URL="https://almalinux.org/"
BUG_REPORT_URL="https://bugs.almalinux.org/"
ALMALINUX_MANTISBT_PROJECT="AlmaLinux-10"
ALMALINUX_MANTISBT_PROJECT_VERSION="10.0"
REDHAT_SUPPORT_PRODUCT="AlmaLinux"
REDHAT_SUPPORT_PRODUCT_VERSION="10.0"
SUPPORT_END=2035-06-01
Ich habe mit diesem Experiment erreicht, was ich haben wollte: eine funktionierende, minimale Alma-Linux-10-Installation in einer im Internet erreichbaren virtuellen Maschine. Ich kann damit experimentieren. Vermutlich wird Hetzner in ein paar Wochen Alma Linux 10 als reguläres Cloud-Installations-Image anbieten. Dann werde ich diese Installation vermutlich wieder abschalten.
In der Vergangenheit habe ich Elevate auch schon auf lokale virtuelle Maschinen mit (nicht besonders wichtigen) Testumgebungen angewendet, ebenfalls zu meiner Zufriedenheit.
Aber ich würde mich niemals trauen, für ein produktiv wichtiges System auf diese Weise ein Upgrade oder womöglich eine Migration auf eine andere Distribution durchzuführen — und schon gar nicht, wenn ich keinen physischen Zugriff auf die Installation habe. Es kann dabei so viel schief gehen! Es ist unklar, ob danach überhaupt eine Reparatur möglich ist, und wenn ja, wie lange diese dauern würde.
Vergessen Sie zuletzt nicht, dass das Upgrade von Alma Linux 9 auf Version 10 aktuell noch im Beta-Test ist. Bei meinem Minimalsystem hat es funktioniert, aber das ist keine Garantie, dass das bei Ihnen auch klappt!
Kurz und gut: Die Kombination aus LEAPP und Elevate bietet eine großartige Möglichkeit, Major Upgrades für RHEL und seine Klone durchzuführen. Das ist ideal für Entwicklungs- und Testsysteme. Aber wie bei jedem Linux-Distributions-Upgrade kann dabei viel schief gehen. Der sichere Weg für produktiv wichtige Installationen ist immer eine Neuinstallation! Sie können dann in aller Ruhe sämtliche Funktionen testen, zum Schluss die Daten migrieren und mit minimaler Downtime eine Umstellung durchführen.
This is the translated version of an article written in German originally. I translated it as a non-German speaking person has shown interest in the topic.
Disclaimer: This tutorial comes without warranty and support. Use at your own risk.
In this tutorial, I would like to show a minimal example on how selected VMDK files of specific VMs can be resized with using the PowerCLI.
This is useful, for example, when so many VMs are affected that the time and effort required to manually enlarge them via the vSphere (web) client seems too great.
Only the resizing of the VMDK file is considered here. The subsequent resizing of the partition and file system within the guest operating system, which is also necessary, is not part of this tutorial.
For a minimal example, from a group of VMs the second and third hard disk of VM-Test-5 and VM-Test-6 are to be enlarged. The respective second hard disk is to be enlarged from 250 GB to 500 GB and the respective third hard disk is to be enlarged from 400 GB to 800 GB.
A working installation of the VMware PowerCLI and the ability to access the vCenter Server is a prerequisite to follow this tutorial.
The following code block shows how the necessary information about the VMs is read out to be processed.
PowerCLI C:\Scripts> Get-VM | Where-Object {$_ | Select-String -pattern "VM-Test-\d"}
Name PowerState Num CPUs MemoryGB
---- ---------- -------- --------
VM-Test-5 PoweredOn 4 24.000
VM-Test-7 PoweredOn 4 16.000
VM-Test-6 PoweredOn 4 24.000
PowerCLI C:\Scripts> Get-VM | Where-Object {$_ | Select-String -pattern "VM-Test-[5,6]{1}"}
Name PowerState Num CPUs MemoryGB
---- ---------- -------- --------
VM-Test-5 PoweredOn 4 24.000
VM-Test-6 PoweredOn 4 24.000
PowerCLI C:\Scripts> $VM = Get-VM | Where-Object {$_ | Select-String -pattern "VM-Test-[5,6]{1}"}
PowerCLI C:\Scripts> Get-VM $VM | Get-HardDisk | FT Parent, Name, CapacityGB -AutoSize
Parent Name CapacityGB
------ ---- ----------
VM-Test-5 Hard disk 1 40
VM-Test-5 Hard disk 2 250
VM-Test-5 Hard disk 3 400
VM-Test-5 Hard disk 4 80
VM-Test-6 Hard disk 1 40
VM-Test-6 Hard disk 2 250
VM-Test-6 Hard disk 3 400
VM-Test-6 Hard disk 4 80From the above output you can see that we want to enlarge the VMDK files which are called „Hard disk 2“ and „Hard disk 3“ respectively.
In the code block that follows, I first define a few variables, then double check that I am selecting the correct VMDK files for the operation, and then I resize them.
PowerCLI C:\Scripts> $HardDisk = 2
PowerCLI C:\Scripts> $HardDisk = "Hard disk " + $HardDisk
PowerCLI C:\Scripts> $HardDiskSize = 500
PowerCLI C:\Scripts> Get-HardDisk -vm $VM | where {$_.Name -eq $HardDisk}
CapacityGB Persistence Filename
---------- ----------- --------
250.000 IndependentPersis... ...STD-2.9T-02] VM-Test-5/VM-Test-5_1.vmdk
250.000 IndependentPersis... ...STD-2.9T-01] VM-Test-6/VM-Test-6_1.vmdk
PowerCLI C:\Scripts> Get-HardDisk -vm $VM | where {$_.Name -eq $HardDisk} | Set-HardDisk -CapacityGB $HardDiskSize -Conf
irm:$false
CapacityGB Persistence Filename
---------- ----------- --------
500.000 IndependentPersis... ...STD-2.9T-02] VM-Test-5/VM-Test-5_1.vmdk
500.000 IndependentPersis... ...STD-2.9T-01] VM-Test-6/VM-Test-6_1.vmdk
PowerCLI C:\Scripts> Get-VM $VM | Get-HardDisk | FT Parent, Name, CapacityGB -AutoSize
Parent Name CapacityGB
------ ---- ----------
VM-Test-5 Hard disk 1 40
VM-Test-5 Hard disk 2 500
VM-Test-5 Hard disk 3 400
VM-Test-5 Hard disk 4 80
VM-Test-6 Hard disk 1 40
VM-Test-6 Hard disk 2 500
VM-Test-6 Hard disk 3 400
VM-Test-6 Hard disk 4 80
PowerCLI C:\Scripts> $HardDisk = 3
PowerCLI C:\Scripts> $HardDisk = "Hard disk " + $HardDisk
PowerCLI C:\Scripts> $HardDiskSize = 800
PowerCLI C:\Scripts> Get-HardDisk -vm $VM | where {$_.Name -eq $HardDisk}
CapacityGB Persistence Filename
---------- ----------- --------
400.000 IndependentPersis... ...STD-2.9T-02] VM-Test-5/VM-Test-5_2.vmdk
400.000 IndependentPersis... ...STD-2.9T-01] VM-Test-6/VM-Test-6_2.vmdk
PowerCLI C:\Scripts> Get-HardDisk -vm $VM | where {$_.Name -eq $HardDisk} | Set-HardDisk -CapacityGB $HardDiskSize -Conf
irm:$false
CapacityGB Persistence Filename
---------- ----------- --------
800.000 IndependentPersis... ...STD-2.9T-02] VM-Test-5/VM-Test-5_2.vmdk
800.000 IndependentPersis... ...STD-2.9T-01] VM-Test-6/VM-Test-6_2.vmdk
PowerCLI C:\Scripts>If the above code block is not self-explanatory, feel free to post your questions about it in the comments. I’ll try to complete the tutorial in a timely manner.
In diesem Tutorial beschreibe ich, wie mithilfe der PowerCLI die RAM-Größe einer virtuellen Maschine (VM) bearbeitet werden kann. Diese Methode lässt sich auch anwenden, um mehrere VMs in einem Arbeitsablauf zu bearbeiten. Dies bietet sich z.B. immer dann an, wenn so viele VMs betroffen sind, dass der Aufwand der manuellen Bearbeitung im vSphere-Client zu groß erscheint.
Die Idee hierzu stammt ursprünglich aus dem Artikel PowerShell Friday: Adding Memory with PowerCLI von Anne Jan Elsinga aus dem Jahr 2015.
Es soll die Größe des Arbeitsspeichers von zunächst einer und anschließend mehrerer VMs bearbeitet werden. Dabei wird gezeigt, wie RAM im laufenden Betrieb erhöht und bei ausgeschalteten VMs reduziert werden kann.
Eine funktionsfähige Installation der VMware PowerCLI und die Möglichkeit den vCenter Server über diese ansprechen zu können, ist Voraussetzung, um diesem Tutorial zu folgen.
Um den RAM einer VM im laufenden Zustand erhöhen zu können, muss die Option Memory Hot Plug der betreffenden VM aktiviert sein.
Zu Beginn verbindet man sich zu der vCenter-Instanz, deren VMs man bearbeiten möchte. Das Kommando hat folgenden Aufbau:
Connect-VIServer [-Server] <String[]> [-Protocol {http | https}] [-User <String>]Beispiel:
Connect-VIServer -Server vcsa.beispiel.de -Protocol https -User alice@vsphere.localDieses Beispiel ist direkt dem Artikel PowerShell Friday: Adding Memory with PowerCLI entnommen.
Der Befehl ist ein Einzeiler:
Get-VM -Name MeineVM | Set-VM -MemoryGB 2Werte kleiner GB werden dezimal spezifiziert:
Get-VM -Name MeineVM |Set-VM -MemoryGB 0.75Angenommen in meiner Umgebung existieren mehrere VMs, die nach dem Muster VM-Test- benannt sind, deren RAM auf 24 GB erhöht werden soll.
Zuerst kann man sich die gewünschte Zielgruppe anzeigen lassen:
PS C:\Users\joerg> Get-VM | Where-Object {$_ | Select-String -pattern "VM-Test-\d"} | Sort
Name PowerState Num CPUs MemoryGB
---- ---------- -------- --------
VM-Test-01 PoweredOn 4 16.000
VM-Test-02 PoweredOn 4 16.000
VM-Test-03 PoweredOn 4 16.000
VM-Test-04 PoweredOn 4 16.000
VM-Test-05 PoweredOn 4 16.000
VM-Test-07 PoweredOn 4 16.000
VM-Test-08 PoweredOn 4 16.000
VM-Test-09 PoweredOn 4 16.000
VM-Test-10 PoweredOn 4 16.000
VM-Test-11 PoweredOn 4 16.000
VM-Test-12 PoweredOn 4 16.000
VM-Test-13 PoweredOn 4 16.000
VM-Test-14 PoweredOn 4 16.000
VM-Test-15 PoweredOn 4 16.000
VM-Test-17 PoweredOn 4 16.000
VM-Test-18 PoweredOn 4 16.000Der Platzhalter ‚\d‘ steht dabei für beliebige Dezimalzahl.
Der RAM kann nun wie folgt auf jeweils 24 GB erhöht werden:
PS C:\Users\joerg> Get-VM | Where-Object {$_ | Select-String -pattern "VM-Test-\d"} | Set-VM -MemoryGB 24
Confirmation
Proceed to configure the following parameters of the virtual machine with name 'VM-Test-01'?
New MemoryMB: 24765MB
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): A
Name PowerState Num CPUs MemoryGB
---- ---------- -------- --------
VM-Test-01 PoweredOn 4 24.000
VM-Test-02 PoweredOn 4 24.000
VM-Test-03 PoweredOn 4 24.000
VM-Test-04 PoweredOn 4 24.000
VM-Test-05 PoweredOn 4 24.000
VM-Test-07 PoweredOn 4 24.000
VM-Test-08 PoweredOn 4 24.000
VM-Test-09 PoweredOn 4 24.000
VM-Test-10 PoweredOn 4 24.000
VM-Test-11 PoweredOn 4 24.000
VM-Test-12 PoweredOn 4 24.000
VM-Test-13 PoweredOn 4 24.000
VM-Test-14 PoweredOn 4 24.000
VM-Test-15 PoweredOn 4 24.000
VM-Test-17 PoweredOn 4 24.000
VM-Test-18 PoweredOn 4 24.000Auch dieses Beispiel ist direkt dem Artikel PowerShell Friday: Adding Memory with PowerCLI entnommen.
Die betroffene VM muss dazu ausgeschaltet werden:
Get-VM -Name MeineVM | Shutdown-VMGuest|Set-VM -MemoryGB 0.25Mit der PowerCLI ist es möglich sich wiederholende Tätigkeiten abarbeiten zu lassen. Dies spart Zeit und Nerven.
Mir hat der Tipp von Anne Jan Elsinga sehr geholfen, weshalb ich die Methode hier für mich, euch und die Nachwelt dokumentiert habe.
Durch diesen Blogbeitrag auf LinuxNews bin ich auf das Tool trash-cli aufmerksam geworden. Installation: # Arch Linux sudo pacman -S trash-cli # Debian/Ubuntu sudo apt install trash-cli # Fedora sudo dnf install trash-cli Befehle:...
