[SOLVED] LVM (via ISCSI) nach Stromausfall kaputt

Homelabguy27

Member
May 26, 2020
14
4
23
32
Hallo, ich bräuchte mal euren Rat!

Problembeschreibung:
Es gab einen Stromausfall. Der Proxmox Server als auch der Truenas Server schalteten sich sofort ab.
Seit dem Vorfall ist das LVM auf dem Proxmox Host kaputt. Die Befehle "vgs", "lvs" als auch "pvs" zeigen keine Informationen an. (die VMs liegen auf einem LVM, welches via ISCSI vom TrueNAS bereitgestellt wird).

dmesg -T meldet auf dem Proxmox seit dem Vorfall folgendes für zwei via ISCSI angebundene LVMs:

Code:
[Tue Aug  1 22:17:18 2023] sd 6:0:0:0: [sdb] Add. Sense: Logical unit not ready, manual intervention required
[Tue Aug  1 22:17:18 2023] sd 6:0:0:0: [sdb] Read Capacity(10) failed: Result: hostbyte=DID_OK driverbyte=DRIVER_OK
[Tue Aug  1 22:17:18 2023] sd 6:0:0:0: [sdb] Sense Key : Not Ready [current]
[Tue Aug  1 22:17:18 2023] sd 6:0:0:0: [sdc] Add. Sense: Logical unit not ready, manual intervention required
[Tue Aug  1 22:17:18 2023] sd 6:0:0:0: [sdc] Read Capacity(10) failed: Result: hostbyte=DID_OK driverbyte=DRIVER_OK
[Tue Aug  1 22:17:18 2023] sd 6:0:0:0: [sdc] Sense Key : Not Ready [current]

lsblk Ausgabe zeigt lediglich:

Code:
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 465.8G  0 disk
├─sda1   8:1    0  1007K  0 part
├─sda2   8:2    0     1G  0 part
└─sda3   8:3    0 464.8G  0 part

(/dev/sda ist lediglich die lokale, ausschließlich für das OS genutzte Disk)

Anschließend entfernte ich testweise eines der LVMs via der Proxmox GUI und versuchte diese erneut hinzuzufügen. Bei verwenden der Auswahl "existing volume groups" wird "no vgs found" angezeigt.

Was ist hier passiert und was kann ich tun? Die Recherche nach den oben genannten Fehlermeldungen ergab, dass es sich meist um Disk defekte handelt.
Das jedoch beide TrueNAS Pools gestorben sind (2x Mirror SSD Pool + 2x Mirror HDD Pool) halte ich für eher unwahrscheinlich, zumal die auf beiden Pools zusätzlich existierenden SMB Windows Shares Datasets zweifelsfrei funktionieren. (SMART Werte offenbar auch einwandfrei)

Ich habe ein aktuelles Backup aller Daten. Dennoch möchte ich gerne verstehen was hier passiert ist, und wie ich das Problem lösen könnte.

Vielen Dank!
 
Last edited:
Deine Beschreibung verstehe ich nicht so ganz.

Du hast ein NAS. Und hast dort via iSCSI LUNs angelegt und dem PVE zugewiesen?
Diese hattest Du dann unter PVE als Physical Volumes für ein LVM verwendet?

Anscheinend gibt es nun Probleme mit den LUNs. Was sagt denn das Log auf der NAS?
 
Deine Beschreibung verstehe ich nicht so ganz.

Du hast ein NAS. Und hast dort via iSCSI LUNs angelegt und dem PVE zugewiesen?
Diese hattest Du dann unter PVE als Physical Volumes für ein LVM verwendet?

Anscheinend gibt es nun Probleme mit den LUNs. Was sagt denn das Log auf der NAS?
Hallo,

genau.

In den TrueNAS Logs habe ich leider nichts auffälliges entdecken können.

Ich bin den in der Proxmox Community "verbreiteten" Weg gegangen und nutze LVM on top auf dem ISCSI (sieh https://pve.proxmox.com/wiki/Storage:_iSCSI)

iSCSI is a block level type storage, and provides no management interface. So it is usually best to export one big LUN, and setup LVM on top of that LUN. You can then use the LVM plugin to manage the storage on that iSCSI LUN.
 
lsblk zeigt dir keine Disk, also wird die nicht gefunden. Funktioniert das iSCSI Netz richtig? Ist das Target vorhanden und hast du schon mal gescannt wie oben beschrieben?
 
  • Like
Reactions: CoolTux
Danke euch beiden!

Dort werden die beiden Pools nach wie vor angezeigt:

Code:
root@pve:~# pvesm scan iscsi 192.168.30.1
iqn.2005-10.org.freenas.ctl:hdd-datastore1 192.168.30.1:3260
iqn.2005-10.org.freenas.ctl:ssd-datastore1 192.168.30.1:3260
 
Dann sollte die Disk ja jetzt per lsblk sichtbar sein. Falls nicht, mal gucken ob Multipath installiert ist und die blacklist greift.
 
Dann sollte die Disk ja jetzt per lsblk sichtbar sein. Falls nicht, mal gucken ob Multipath installiert ist und die blacklist greift.
Leider nicht, ich habe ja nichts geändert.

Multipath ist nicht installiert, war es zuvor jedoch auch nicht.
Ich habe dazu eben auch sicherheitshalber die dpkg Logs durchsucht.
 
Zeige mal bitte

/etc/pve/storage.cfg

Code:
less /etc/pve/storage.cfg
dir: local
        path /var/lib/vz
        content vztmpl,iso,backup

zfspool: local-zfs
        pool rpool/data
        content images,rootdir
        sparse 1

lvm: hdd-datastore1-lvm
        vgname hdd-datastore1-vg
        content rootdir,images
        nodes pve
        shared 0

nfs: nfs-backups
        export /mnt/nfs-storage/pve-backups
        path /mnt/pve/nfs-backups
        server 192.168.30.1
        content images,snippets,backup
        prune-backups keep-all=1

iscsi: hdd-datastore1
        portal 192.168.30.1
        target iqn.2005-10.org.freenas.ctl:hdd-datastore1
        content none

iscsi: ssd-datastore1
        portal 192.168.30.1
        target iqn.2005-10.org.freenas.ctl:ssd-datastore1
        content none

Ich habe gestern testweise mal das lvm für den ssd pool entfernt, mit dem Versuch es erneut hinzuzufügen. (Nicht wundern das dieses hier fehlt, der andere Pool (lvm: hdd-datastore1-lvm) ist hier jedoch noch zu sehen.)
 
Was mich wundert, wenn du die iSCSI Targets siehst und gemountet hast, muss lsblk die Devices anzeigen.
 
Was mich wundert, wenn du die iSCSI Targets siehst und gemountet hast, muss lsblk die Devices anzeigen.
So isses, man sieht lediglich die lokale im Proxmox Server verbaute Disk.

Ich habe mal Screenshots angehängt, wie das ganze in Proxmox ausschaut.

Was ich noch versuchen könnte wäre, das ISCSI mal komplett neu einzurichten (auch seitens TrueNAS). Aber bin ich hier an der richtigen Stelle? Denn die ISCSI Verbindung scheint ja offenbar zu funktionieren, lediglich das LVM hat irgendein unerklärliches Problem.
 

Attachments

  • Unbenannt.JPG
    Unbenannt.JPG
    31.3 KB · Views: 8
  • Unbenannt2.JPG
    Unbenannt2.JPG
    55.3 KB · Views: 7
  • Unbenannt3.JPG
    Unbenannt3.JPG
    25.9 KB · Views: 7
  • Unbenannt4.JPG
    Unbenannt4.JPG
    32 KB · Views: 7
  • Unbenannt5.JPG
    Unbenannt5.JPG
    239.3 KB · Views: 8
Immer der Reihe nach. LVM ist eine rein lokale Sache auf dem Host. Dazu muss aber erstmal ein Blockdevice vorhanden sein. Also /dev/sdb und so. Das sollte eigentlich das iscsi einrichten.

Mach mal bitte

Code:
lsscsi

Hast du eine /etc/iscsid.conf dann zeige bitte mal den Inhalt.
 
Last edited:
So isses, man sieht lediglich die lokale im Proxmox Server verbaute Disk.

Ich habe mal Screenshots angehängt, wie das ganze in Proxmox ausschaut.

Was ich noch versuchen könnte wäre, das ISCSI mal komplett neu einzurichten (auch seitens TrueNAS). Aber bin ich hier an der richtigen Stelle? Denn die ISCSI Verbindung scheint ja offenbar zu funktionieren, lediglich das LVM hat irgendein unerklärliches Problem.
Hi, wie Leon geschrieben hat, immer der Reihe nach. Das LVM ist vollkommen egal und interessiert an diesem Punkt noch gar nicht.
Dein Problem ist noch beim Transportweg, Zuerst muss die Disk per iSCSI sauber erkannt werden, erst dann können weitere Funktionen wie z.B. LVM funktionieren. Wenn die Disks wieder das sind, ist garantiert auch das LVM und deine VMs wieder da.
 
Moin,

den Befehl lsscsi gibt es auf dem pve offenbar nicht.

/etc/iscsi/iscsid.conf: (die Config wurde von mir nicht verändert und sollte dem default entsprechen)
INI:
#
# Open-iSCSI default configuration.
# Could be located at /etc/iscsi/iscsid.conf or ~/.iscsid.conf
#
# Note: To set any of these values for a specific node/session run
# the iscsiadm --mode node --op command for the value. See the README
# and man page for iscsiadm for details on the --op command.
#


######################
# iscsid daemon config
######################
#
# If you want iscsid to start the first time an iscsi tool
# needs to access it, instead of starting it when the init
# scripts run, set the iscsid startup command here. This
# should normally only need to be done by distro package
# maintainers. If you leave the iscsid daemon running all
# the time then leave this attribute commented out.
#
# Default for Fedora and RHEL. (uncomment to activate).
# iscsid.startup = /bin/systemctl start iscsid.socket iscsiuio.socket
#
# Default if you are not using systemd (uncomment to activate)
# iscsid.startup = /usr/bin/service start iscsid


# Check for active mounts on devices reachable through a session
# and refuse to logout if there are any.  Defaults to "No".
# iscsid.safe_logout = Yes


#############################
# NIC/HBA and driver settings
#############################
# open-iscsi can create a session and bind it to a NIC/HBA.
# To set this up see the example iface config file.


#*****************
# Startup settings
#*****************


# To request that the iscsi initd scripts startup a session set to "automatic".
# node.startup = automatic
#
# To manually startup the session set to "manual". The default is manual.
node.startup = manual


# For "automatic" startup nodes, setting this to "Yes" will try logins on each
# available iface until one succeeds, and then stop.  The default "No" will try
# logins on all available ifaces simultaneously.
node.leading_login = No


# *************
# CHAP Settings
# *************


# To enable CHAP authentication set node.session.auth.authmethod
# to CHAP. The default is None.
#node.session.auth.authmethod = CHAP


# To configure which CHAP algorithms to enable set
# node.session.auth.chap_algs to a comma seperated list.
# The algorithms should be listen with most prefered first.
# Valid values are MD5, SHA1, SHA256, and SHA3-256.
# The default is MD5.
#node.session.auth.chap_algs = SHA3-256,SHA256,SHA1,MD5


# To set a CHAP username and password for initiator
# authentication by the target(s), uncomment the following lines:
#node.session.auth.username = username
#node.session.auth.password = password


# To set a CHAP username and password for target(s)
# authentication by the initiator, uncomment the following lines:
#node.session.auth.username_in = username_in
#node.session.auth.password_in = password_in


# To enable CHAP authentication for a discovery session to the target
# set discovery.sendtargets.auth.authmethod to CHAP. The default is None.
#discovery.sendtargets.auth.authmethod = CHAP


# To set a discovery session CHAP username and password for the initiator
# authentication by the target(s), uncomment the following lines:
#discovery.sendtargets.auth.username = username
#discovery.sendtargets.auth.password = password


# To set a discovery session CHAP username and password for target(s)
# authentication by the initiator, uncomment the following lines:
#discovery.sendtargets.auth.username_in = username_in
#discovery.sendtargets.auth.password_in = password_in


# ********
# Timeouts
# ********
#
# See the iSCSI README's Advanced Configuration section for tips
# on setting timeouts when using multipath or doing root over iSCSI.
#
# To specify the length of time to wait for session re-establishment
# before failing SCSI commands back to the application when running
# the Linux SCSI Layer error handler, edit the line.
# The value is in seconds and the default is 120 seconds.
# Special values:
# - If the value is 0, IO will be failed immediately.
# - If the value is less than 0, IO will remain queued until the session
# is logged back in, or until the user runs the logout command.
node.session.timeo.replacement_timeout = 120


# To specify the time to wait for login to complete, edit the line.
# The value is in seconds and the default is 15 seconds.
node.conn[0].timeo.login_timeout = 15


# To specify the time to wait for logout to complete, edit the line.
# The value is in seconds and the default is 15 seconds.
node.conn[0].timeo.logout_timeout = 15


# Time interval to wait for on connection before sending a ping.
node.conn[0].timeo.noop_out_interval = 5


# To specify the time to wait for a Nop-out response before failing
# the connection, edit this line. Failing the connection will
# cause IO to be failed back to the SCSI layer. If using dm-multipath
# this will cause the IO to be failed to the multipath layer.
node.conn[0].timeo.noop_out_timeout = 5


# To specify the time to wait for abort response before
# failing the operation and trying a logical unit reset edit the line.
# The value is in seconds and the default is 15 seconds.
node.session.err_timeo.abort_timeout = 15


# To specify the time to wait for a logical unit response
# before failing the operation and trying session re-establishment
# edit the line.
# The value is in seconds and the default is 30 seconds.
node.session.err_timeo.lu_reset_timeout = 30


# To specify the time to wait for a target response
# before failing the operation and trying session re-establishment
# edit the line.
# The value is in seconds and the default is 30 seconds.
node.session.err_timeo.tgt_reset_timeout = 30




#******
# Retry
#******


# To specify the number of times iscsid should retry a login
# if the login attempt fails due to the node.conn[0].timeo.login_timeout
# expiring modify the following line. Note that if the login fails
# quickly (before node.conn[0].timeo.login_timeout fires) because the network
# layer or the target returns an error, iscsid may retry the login more than
# node.session.initial_login_retry_max times.
#
# This retry count along with node.conn[0].timeo.login_timeout
# determines the maximum amount of time iscsid will try to
# establish the initial login. node.session.initial_login_retry_max is
# multiplied by the node.conn[0].timeo.login_timeout to determine the
# maximum amount.
#
# The default node.session.initial_login_retry_max is 8 and
# node.conn[0].timeo.login_timeout is 15 so we have:
#
# node.conn[0].timeo.login_timeout * node.session.initial_login_retry_max =
#                                120 seconds
#
# Valid values are any integer value. This only
# affects the initial login. Setting it to a high value can slow
# down the iscsi service startup. Setting it to a low value can
# cause a session to not get logged into, if there are distuptions
# during startup or if the network is not ready at that time.
node.session.initial_login_retry_max = 8


################################
# session and device queue depth
################################


# To control how many commands the session will queue set
# node.session.cmds_max to an integer between 2 and 2048 that is also
# a power of 2. The default is 128.
node.session.cmds_max = 128


# To control the device's queue depth set node.session.queue_depth
# to a value between 1 and 1024. The default is 32.
node.session.queue_depth = 32


##################################
# MISC SYSTEM PERFORMANCE SETTINGS
##################################


# For software iscsi (iscsi_tcp) and iser (ib_iser) each session
# has a thread used to transmit or queue data to the hardware. For
# cxgb3i you will get a thread per host.
#
# Setting the thread's priority to a lower value can lead to higher throughput
# and lower latencies. The lowest value is -20. Setting the priority to
# a higher value, can lead to reduced IO performance, but if you are seeing
# the iscsi or scsi threads dominate the use of the CPU then you may want
# to set this value higher.
#
# Note: For cxgb3i you must set all sessions to the same value, or the
# behavior is not defined.
#
# The default value is -20. The setting must be between -20 and 20.
node.session.xmit_thread_priority = -20




#***************
# iSCSI settings
#***************


# To enable R2T flow control (i.e., the initiator must wait for an R2T
# command before sending any data), uncomment the following line:
#
#node.session.iscsi.InitialR2T = Yes
#
# To disable R2T flow control (i.e., the initiator has an implied
# initial R2T of "FirstBurstLength" at offset 0), uncomment the following line:
#
# The defaults is No.
node.session.iscsi.InitialR2T = No


#
# To disable immediate data (i.e., the initiator does not send
# unsolicited data with the iSCSI command PDU), uncomment the following line:
#
#node.session.iscsi.ImmediateData = No
#
# To enable immediate data (i.e., the initiator sends unsolicited data
# with the iSCSI command packet), uncomment the following line:
#
# The default is Yes
node.session.iscsi.ImmediateData = Yes


# To specify the maximum number of unsolicited data bytes the initiator
# can send in an iSCSI PDU to a target, edit the following line.
#
# The value is the number of bytes in the range of 512 to (2^24-1) and
# the default is 262144
node.session.iscsi.FirstBurstLength = 262144


# To specify the maximum SCSI payload that the initiator will negotiate
# with the target for, edit the following line.
#
# The value is the number of bytes in the range of 512 to (2^24-1) and
# the defauls it 16776192
node.session.iscsi.MaxBurstLength = 16776192


# To specify the maximum number of data bytes the initiator can receive
# in an iSCSI PDU from a target, edit the following line.
#
# The value is the number of bytes in the range of 512 to (2^24-1) and
# the default is 262144
node.conn[0].iscsi.MaxRecvDataSegmentLength = 262144


# To specify the maximum number of data bytes the initiator will send
# in an iSCSI PDU to the target, edit the following line.
#
# The value is the number of bytes in the range of 512 to (2^24-1).
# Zero is a special case. If set to zero, the initiator will use
# the target's MaxRecvDataSegmentLength for the MaxXmitDataSegmentLength.
# The default is 0.
node.conn[0].iscsi.MaxXmitDataSegmentLength = 0


# To specify the maximum number of data bytes the initiator can receive
# in an iSCSI PDU from a target during a discovery session, edit the
# following line.
#
# The value is the number of bytes in the range of 512 to (2^24-1) and
# the default is 32768
#
discovery.sendtargets.iscsi.MaxRecvDataSegmentLength = 32768


# To allow the targets to control the setting of the digest checking,
# with the initiator requesting a preference of enabling the checking, uncomment# one or both of the following lines:
#node.conn[0].iscsi.HeaderDigest = CRC32C,None
#node.conn[0].iscsi.DataDigest = CRC32C,None
#
# To allow the targets to control the setting of the digest checking,
# with the initiator requesting a preference of disabling the checking,
# uncomment one or both of the following lines:
#node.conn[0].iscsi.HeaderDigest = None,CRC32C
#node.conn[0].iscsi.DataDigest = None,CRC32C
#
# To enable CRC32C digest checking for the header and/or data part of
# iSCSI PDUs, uncomment one or both of the following lines:
#node.conn[0].iscsi.HeaderDigest = CRC32C
#node.conn[0].iscsi.DataDigest = CRC32C
#
# To disable digest checking for the header and/or data part of
# iSCSI PDUs, uncomment one or both of the following lines:
#node.conn[0].iscsi.HeaderDigest = None
#node.conn[0].iscsi.DataDigest = None
#
# The default is to never use DataDigests or HeaderDigests.
#


# For multipath configurations, you may want more than one session to be
# created on each iface record.  If node.session.nr_sessions is greater
# than 1, performing a 'login' for that node will ensure that the
# appropriate number of sessions is created.
node.session.nr_sessions = 1


# When iscsid starts up it recovers existing sessions, if possible.
# If the target for a session has gone away when this occurs, the
# iscsid daemon normally tries to reestablish each session,
# in succession, in the background, by trying again every two
# seconds, until all sessions are restored. This configuration
# variable can limits the number of retries for each session.
# For example, setting reopen_max=150 would mean that each session
# recovery was limited to about five minutes.
#
node.session.reopen_max = 0


#************
# Workarounds
#************


# Some targets like IET prefer after an initiator has sent a task
# management function like an ABORT TASK or LOGICAL UNIT RESET, that
# it does not respond to PDUs like R2Ts. To enable this behavior uncomment
# the following line (The default behavior is Yes):
node.session.iscsi.FastAbort = Yes


# Some targets like Equalogic prefer that after an initiator has sent
# a task management function like an ABORT TASK or LOGICAL UNIT RESET, that
# it continue to respond to R2Ts. To enable this uncomment this line
# node.session.iscsi.FastAbort = No


# To prevent doing automatic scans that would add unwanted luns to the system
# we can disable them and have sessions only do manually requested scans.
# Automatic scans are performed on startup, on login, and on AEN/AER reception
# on devices supporting it.  For HW drivers all sessions will use the value
# defined in the configuration file.  This configuration option is independent
# of scsi_mod scan parameter. (The default behavior is auto):
node.session.scan = auto
 
INI:
#
#*****************
# Startup settings
#*****************


# To request that the iscsi initd scripts startup a session set to "automatic".
# node.startup = automatic
#
# To manually startup the session set to "manual". The default is manual.
node.startup = manual


# For "automatic" startup nodes, setting this to "Yes" will try logins on each
# available iface until one succeeds, and then stop.  The default "No" will try
# logins on all available ifaces simultaneously.
node.leading_login = No
Da steht doch schon alles dokumentiert.
Wenn du iSCSI Disks verwendest solltest du den startup natürlich auch auf automatic stellen und den Login natürlich auch.
Sonst hat der PVE keinerlei Möglichkeit beim starten die Disks zu finden und du musst nach jedem Reboot alles manuell machen.
 
Was ich etwas seltsam finde ist das es ja wohl vorher ging und erst nach einem Stromausfall der Fehler kam

Code:
[Tue Aug  1 22:17:18 2023] sd 6:0:0:0: [sdb] Add. Sense: Logical unit not ready, manual intervention required
[Tue Aug  1 22:17:18 2023] sd 6:0:0:0: [sdb] Read Capacity(10) failed: Result: hostbyte=DID_OK driverbyte=DRIVER_OK
[Tue Aug  1 22:17:18 2023] sd 6:0:0:0: [sdb] Sense Key : Not Ready [current]

Alles was ich zu dieser Meldung so an sich finde ist, dass immer auf das Storage selbst verwiesen wird. Also auf die Einheit welche die iSCSI LUNs zur Verfügung stellt. Angeblich soll es da dann immer ein Problem geben laut Internet.

Ich würde auch mal versuchen die Konfig so ein zu richten das dort Automatisch gestartet wird

node.startup = automatic
 
Code:
[Tue Aug  1 22:17:18 2023] sd 6:0:0:0: [sdb] Add. Sense: Logical unit not ready, manual intervention required
Diese Meldung sagt aber eindeutig, dass dein Target nicht OK ist. Also das Storage präsentiert nicht richtig.
 
  • Like
Reactions: CoolTux
Was ich etwas seltsam finde ist das es ja wohl vorher ging und erst nach einem Stromausfall der Fehler kam

Exakt, der Proxmox, das TrueNAS als auch der Switch auf dem das VLAN liegt wurden über die Zeit mehrere Male neugestartet, dabei kam es nie zu Problemen.

Code:
Alles was ich zu dieser Meldung so an sich finde ist, dass immer auf das Storage selbst verwiesen wird. Also auf die Einheit welche die iSCSI LUNs zur Verfügung stellt. Angeblich soll es da dann immer ein Problem geben laut Internet.

Ich würde auch mal versuchen die Konfig so ein zu richten das dort Automatisch gestartet wird

node.startup = automatic

Habe ich nun eben mal probiert und den Host rebooted, das Verhalten hat sich aber scheinbar nicht geändert.

Diese Meldung sagt aber eindeutig, dass dein Target nicht OK ist. Also das Storage präsentiert nicht richtig.

Hm...sonst sollte ich vllt. doch nochmal verstärkt Richtung TrueNAS forschen.
 
Last edited:
  • Like
Reactions: Falk R.
Nun...was soll ich sagen...

Ich habe nachdem ich auch auf dem TrueNAS keine entsprechenden Log-Einträge entdecken konnte, radikal die ISCSI Verbindung auf beiden Geräten einmal entfernt und neu eingerichtet. Und siehe da, alles ist wieder da...und die VMs laufen auch wieder.

1691084949915.png

Wie so etwas passieren konnte muss ich wohl nicht verstehen.
Von einer so verbreiteten Software wie TrueNAS hätte ich erwartet, dass so etwas einfach nicht so passiert, gerade wenn man im ZFS Kontext und Co unterwegs ist und so viele Jahre Erfahrung hat. Aber normalerweise hat man ja auch eine USV und bla, ich weiß... o_O

Jedenfalls... vielen Dank euch allen für die richtige Spur, ich war nämlich inzwischen gut vom Weg abgekommen und fast fest davon überzeugt Proxmox sei schuld!

Das Wochenende zum basteln ist damit ggf. wieder im Rennen :D
 
  • Like
Reactions: Falk R. and CoolTux

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!