Hookscript wird nicht genutzt

Nuffi · Jul 15, 2024

Hallo zusammen,
Ich betreibe Proxmox auf einem System mit nur einer GPU und möchte diese an VM's durchreichen und nach dem Shutdown der VM wieder an den Host binden.
Dazu habe ich ein Bashscript, dass als Hookscript die Treiber hin und her wechselt. Solange ich das manuell teste funktioniert das auch, allerdings scheint der "post-stop" Hook bei einem Shutdown aus der VM (EndeavourOS oder WIN11) nicht genutzt zu werden. Im Beispielscript steht für "pre-stop" "#Will not be executed if the guest is stopped from within e.g., with a 'poweroff'". Gilt das auch für "post-stop" und gibt es eine alternative für reguläre Shutdowns aus den VM's heraus?

Gruß
Nuffi

aaron · Jul 15, 2024

IIRC sollte post-stop immer ausgeführt werden. Es wird nicht im Kontext des normalen Shutdowns ausgeführt, sondern vom Dienst der hinter einer VM "aufräumt". Du kannst das schnell testen, indem du im "post-stop" z.B. das aktuelle DatumZeit in ein File schreiben lässt. Etwas in die Richtung von folgendem CLI/Bash Befehlen.

Code:

echo $(date) >> /tmp/vmshutdown

Nuffi · Jul 15, 2024

Ich hab schon eine Ausgabe für "post-stop", allerdings scheint es so, als würde das nur getriggert werden, wenn ich die VM vom Host aus herunterfahre, aber nicht wenn ich innerhalb der VM's den Shutdown aus dem OS nutze. Hier mal mein Hookscript:

Bash:

#!/bin/bash

EXECUTION_PHASE=$2;
LOGGING=/var/log/gpu-reset.log;
gpu_driver="$(find /sys | grep "drivers.*$gpu"|awk -F '/' '{print $(NF-1)}')"
gpu="0000:b5:00.0"
aud="0000:b5:00.1"

#check if drivectl is installed
if ! command -v "driverctl" &> /dev/null
then
    echo " driverctl could not be found"
    exit 1
fi

/usr/bin/date >> $LOGGING;
# Main
if [[ "$EXECUTION_PHASE" == "pre-start" ]]; then
    /usr/bin/echo "Phase $EXECUTION_PHASE: Switch PCIe drivers to vfio-pci" >> $LOGGING;
    if [[ "$gpu_driver" != "vfio-pci" ]]; then
        driverctl set-override $gpu vfio-pci
        driverctl set-override $aud vfio-pci
        /usr/bin/echo "PCIe devices have been switched to vfio-pci ($gpu | $aud)" >> $LOGGING;
    fi
fi

if [[ "$EXECUTION_PHASE" == "post-stop" ]]; then
    /usr/bin/echo "Phase $EXECUTION_PHASE: Switch PCIe drivers to amdgpu" >> $LOGGING;
    driverctl set-override $gpu amdgpu
    driverctl set-override $aud snd_hda_intel
    /usr/bin/echo "PCIe devices have been switched to amdgpu ($gpu | $aud)" >> $LOGGING;      
fi

/usr/bin/echo "##################" >> $LOGGING;

aaron · Jul 15, 2024

ich hab das script mal genommen und das ganze `driverctl` spezifische auskommentiert. Es wird bei mir auch ausgeführt, wenn eine VM stoppt. Auch wenn der shutdown von innerhalb der VM kommt.

Evtl. macht das Skript selbst probleme? Versuch mal `shellcheck` drüber laufen zu lassen und es manuell zu starten, mit den folgenden Zeilen am Anfang:

Code:

set -e;
set -x;

Ersteres bewirkt, dass das Script bei Fehlern abbricht, letzteres, dass jede Zeile, die ausgeführt wird, geprintet wird.

/pfad/zum/script.bash 999 post-stop

Nuffi · Jul 15, 2024

shellcheck war ein guter Hinweis, da haben sich gestern Nacht einige Fehler eingeschlichen (Script oben ist aktualisiert). Das ändert aber nichts daran, dass das "post-stop" event nicht getriggert wird.

Das Skript läuft wie erwartet durch und gibt den erwarteten Output:

Code:

+ EXECUTION_PHASE=post-stop
+ LOGGING=/var/log/gpu-reset.log
++ find /sys
++ grep 'drivers.*'
++ awk -F / '{print $(NF-1)}'
+ gpu_driver='0000:1a:00.1
+ gpu=0000:b5:00.0
+ aud=0000:b5:00.1
+ command -v driverctl
+ /usr/bin/date
+ [[ post-stop == \p\r\e\-\s\t\a\r\t ]]
+ [[ post-stop == \p\o\s\t\-\s\t\o\p ]]
+ /usr/bin/echo 'Phase post-stop: Switch PCIe drivers to amdgpu'
+ driverctl set-override 0000:b5:00.0 amdgpu
+ driverctl set-override 0000:b5:00.1 snd_hda_intel
+ /usr/bin/echo 'PCIe devices have been switched to amdgpu (0000:b5:00.0 | 0000:b5:00.1)'
+ /usr/bin/echo '##################'

Damit werden auch die Treiber geändert wie gewollt:

Code:

b5:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 21 [Radeon RX 6800/6800 XT / 6900 XT] [1002:73bf] (rev c1)
        Subsystem: Micro-Star International Co., Ltd. [MSI] Navi 21 [Radeon RX 6800/6800 XT / 6900 XT] [1462:3953]
        Kernel driver in use: amdgpu
        Kernel modules: amdgpu
b5:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 21/23 HDMI/DP Audio Controller [1002:ab28]
        Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Navi 21/23 HDMI/DP Audio Controller [1002:ab28]
        Kernel driver in use: snd_hda_intel
        Kernel modules: snd_hda_intel

Sobald das allerdings über "post-stop" laufen soll steht in dem Log folgendes:
Bei "qm stop 200" auf der Konsole:

Code:

Mon Jul 15 14:11:46 CEST 2024
Phase pre-start: Switch PCIe drivers to vfio-pci
PCIe devices have been switched to vfio-pci (0000:b5:00.0 | 0000:b5:00.1)
##################
Mon Jul 15 14:11:50 CEST 2024
##################
Mon Jul 15 14:12:21 CEST 2024
##################
Mon Jul 15 14:12:23 CEST 2024
Phase post-stop: Switch PCIe drivers to amdgpu
PCIe devices have been switched to amdgpu (0000:b5:00.0 | 0000:b5:00.1)
##################

und beim shutdown innerhalb der VM:

Code:

#################
Mon Jul 15 14:20:57 CEST 2024
Phase pre-start: Switch PCIe drivers to vfio-pci
PCIe devices have been switched to vfio-pci (0000:b5:00.0 | 0000:b5:00.1)
##################
Mon Jul 15 14:21:01 CEST 2024
##################
/var/log/gpu-reset.log (END)

Kann es sein, dass beim Shutdown in der VM irgendwas übrig bleibt von der VM, sodass Proxmox das Post-stop nicht ausführt?

Nuffi · Jul 15, 2024

Nach kurzer Suche habe ich z.B. das gefunden (Bei abgeschalteter VM mit ID 200) :

Code:

root@pve:~# ll /var/run/qemu-server/
total 4
-rw------- 1 root root  0 Jul 15 13:53 200-swtpm.log
-rw-r--r-- 1 root root 54 Jul 15 14:21 pci-id-reservations
-rw-r--r-- 1 root root  0 Jul 15 13:53 pci-id-reservations.lock
root@pve:~#

aaron · Jul 15, 2024

Läuft der qmeventd Service? systemctl status qmeventd.service
Dieser Dienst ist dafür verantwortlich aufzuräumen, sobald ein Gast nicht mehr läuft und auch die Hookscripts mit der "post-stop" Phase auszuführen.
Wenn du in deinem Script die set -x; Option zu Beginn setzt, solltest du im Journal auch diesen Output sehen.
journcalctl -u qmeventd.service

Nuffi · Jul 15, 2024

aaron said:
Läuft der qmeventd Service? systemctl status qmeventd.service
Dieser Dienst ist dafür verantwortlich aufzuräumen, sobald ein Gast nicht mehr läuft und auch die Hookscripts mit der "post-stop" Phase auszuführen.
Wenn du in deinem Script die set -x; Option zu Beginn setzt, solltest du im Journal auch diesen Output sehen.
journcalctl -u qmeventd.service

Ja, der Dienst läuft, aber die logs sehen verdächtig aus:

Code:

root@pve:~# systemctl status qmeventd.service
● qmeventd.service - PVE Qemu Event Daemon
     Loaded: loaded (/lib/systemd/system/qmeventd.service; enabled; preset: enabled)
     Active: active (running) since Mon 2024-07-15 08:32:52 CEST; 6h ago
    Process: 1973 ExecStart=/usr/sbin/qmeventd /var/run/qmeventd.sock (code=exited, status=0/SUCCESS)
   Main PID: 1978 (qmeventd)
      Tasks: 1 (limit: 230129)
     Memory: 412.0K
        CPU: 12.226s
     CGroup: /system.slice/qmeventd.service
             └─1978 /usr/sbin/qmeventd /var/run/qmeventd.sock

Jul 15 14:12:23 pve qmeventd[85842]: + /usr/bin/echo 'Phase post-stop: Switch PCIe drivers to amdgpu'
Jul 15 14:12:23 pve qmeventd[85842]: + driverctl set-override 0000:b5:00.0 amdgpu
Jul 15 14:12:23 pve qmeventd[85842]: driverctl: failed to bind device 0000:b5:00.0 to driver amdgpu
Jul 15 14:12:23 pve qmeventd[85842]: + driverctl set-override 0000:b5:00.1 snd_hda_intel
Jul 15 14:12:23 pve qmeventd[85842]: + /usr/bin/echo 'PCIe devices have been switched to amdgpu (0000:b5:00.0 | 0000:b5:00.1)'
Jul 15 14:12:23 pve qmeventd[85842]: + /usr/bin/echo '##################'
Jul 15 14:12:23 pve qmeventd[85842]: Finished cleanup for 200
Jul 15 14:22:15 pve qmeventd[1978]: read: Connection reset by peer
Jul 15 14:22:16 pve qmeventd[87892]: Starting cleanup for 200
Jul 15 14:22:16 pve qmeventd[87892]: vm still running

aaron · Jul 15, 2024

Mit journcalctl -u qmeventd.service kannst du dir den gesamten Inhalt der Logs ansehen. Hoffentlich hilft dir das weiter beim Troubleshooten wieso es nicht ganz so klappt wie erwartet.

Mit journcalctl -u qmeventd.service -f kannst du live mitsehen was bei den Logs passiert.

Nuffi · Jul 15, 2024

Beide VM's mit GPU passthrough verhalten sich gleich:

Code:

#VM shutdown mit `qm stop 200`:
Jul 15 15:47:54 pve qmeventd[1978]: read: Connection reset by peer                                                     
Jul 15 15:47:55 pve qmeventd[106157]: Starting cleanup for 200                                                         
Jul 15 15:47:55 pve qmeventd[106157]: trying to acquire lock...                                                        
Jul 15 15:47:56 pve qmeventd[106157]:  OK                                                                              
Jul 15 15:47:56 pve qmeventd[106157]: + EXECUTION_PHASE=post-stop                                                      
Jul 15 15:47:56 pve qmeventd[106157]: + LOGGING=/var/log/gpu-reset.log                                                 
Jul 15 15:47:56 pve qmeventd[106157]: ++ find /sys                                                                     
Jul 15 15:47:56 pve qmeventd[106157]: ++ grep 'drivers.*'                                                              
Jul 15 15:47:56 pve qmeventd[106157]: ++ awk -F / '{print $(NF-1)}'                                                    
Jul 15 15:47:56 pve qmeventd[106157]: + gpu_driver='0000:1a:00.1                                                       
Jul 15 15:47:56 pve qmeventd[106157]: 0000:1a:00.2                                                                     
Jul 15 15:47:56 pve qmeventd[106157]: 0000:1a:00.0                                                                     
Jul 15 15:47:56 pve qmeventd[106157]: 0000:1a:00.3
....
Jul 15 15:47:56 pve qmeventd[106157]: + gpu=0000:b5:00.0
Jul 15 15:47:56 pve qmeventd[106157]: + aud=0000:b5:00.1
Jul 15 15:47:56 pve qmeventd[106157]: + command -v driverctl
Jul 15 15:47:56 pve qmeventd[106157]: + /usr/bin/date
Jul 15 15:47:56 pve qmeventd[106157]: + [[ post-stop == \p\r\e\-\s\t\a\r\t ]]
Jul 15 15:47:56 pve qmeventd[106157]: + [[ post-stop == \p\o\s\t\-\s\t\o\p ]]
Jul 15 15:47:56 pve qmeventd[106157]: + /usr/bin/echo 'Phase post-stop: Switch PCIe drivers to amdgpu'
Jul 15 15:47:56 pve qmeventd[106157]: + driverctl set-override 0000:b5:00.0 amdgpu
Jul 15 15:47:56 pve qmeventd[106157]: driverctl: failed to bind device 0000:b5:00.0 to driver amdgpu
Jul 15 15:47:56 pve qmeventd[106157]: + driverctl set-override 0000:b5:00.1 snd_hda_intel
Jul 15 15:47:57 pve qmeventd[106157]: + /usr/bin/echo 'PCIe devices have been switched to amdgpu (0000:b5:00.0 | 0000:b5:00.1)'
Jul 15 15:47:57 pve qmeventd[106157]: + /usr/bin/echo '##################'
Jul 15 15:47:57 pve qmeventd[106157]: Finished cleanup for 200

#VM shutdown "in der VM":
Jul 15 15:33:56 pve qmeventd[1978]: read: Connection reset by peer
Jul 15 15:33:56 pve qmeventd[103595]: Starting cleanup for 300
Jul 15 15:33:56 pve qmeventd[103595]: vm still running

Nuffi · Jul 16, 2024

Soweit ich das sehe steigt Proxmox an dieser Stelle aus, wenn ich den Shutdown im Gast mache:

**PVE/CLI/qm.pm**:

Perl:

904     code => sub {
 905         my ($param) = @_;
 906
 907         my $vmid = $param->{vmid};
 908         my $clean = $param->{'clean-shutdown'};
 909         my $guest = $param->{'guest-requested'};
 910         my $restart = 0;
 911
 912         # return if we do not have the config anymore
 913         return if !-f PVE::QemuConfig->config_file($vmid);
 914
 915         my $storecfg = PVE::Storage::config();
 916         warn "Starting cleanup for $vmid\n";
 917
 918         # mdev cleanup can take a while, so wait up to 60 seconds
 919         PVE::QemuConfig->lock_config_full($vmid, 60, sub {
 920             my $conf = PVE::QemuConfig->load_config ($vmid);
 921             my $pid = PVE::QemuServer::check_running ($vmid);
 922             die "vm still running\n" if $pid;
 923
 924             if (!$clean) {
 925                 # we have to cleanup the tap devices after a crash
 926
 927                 foreach my $opt (keys %$conf) {
 928                     next if $opt !~  m/^net(\d+)$/;
 929                     my $interface = $1;
 930                     PVE::Network::tap_unplug("tap${vmid}i${interface}");
 931                 }
 932             }
 933
 934             if (!$clean || $guest) {
 935                 # vm was shutdown from inside the guest or crashed, doing api cleanup
 936                 PVE::QemuServer::vm_stop_cleanup($storecfg, $vmid, $conf, 0, 0);
 937             }
 938             PVE::GuestHelpers::exec_hookscript($conf, $vmid, 'post-stop');

In Zeile 922 geht's dann nicht weiter und der "post-stop" Hook (Zeile 938) wird nie erreicht.

Nuffi · Jul 16, 2024

Ich hab mal die Variablen mit ausgegeben (Z. 923 - 925):

Code:

918     # mdev cleanup can take a while, so wait up to 60 seconds
919     PVE::QemuConfig->lock_config_full($vmid, 60, sub {       
920         my $conf = PVE::QemuConfig->load_config ($vmid);     
921         my $pid = PVE::QemuServer::check_running ($vmid);   
922         ##REMOVE AFTER TEST                                 
923         print "Content \$vmid: $vmid\n";                     
924         print "Content \$conf: $conf\n";                     
925         print "Content \$pid: $pid\n";                       
926         ##                                                   
927         die "vm still running\n" if $pid;

Dann sieht man, dass der Inhalt von $pid unterschiedlich ist, jenachdem wie man die VM stoppt:

Code:

Stop CLI:
Jul 16 15:37:02 pve qmeventd[49081]: Starting cleanup for 200
Jul 16 15:37:02 pve qmeventd[49081]: trying to acquire lock...
Jul 16 15:37:03 pve qmeventd[49081]:  OK                     
Jul 16 15:37:03 pve qmeventd[49081]: Content $vmid: 200
Jul 16 15:37:03 pve qmeventd[49081]: Content $conf: HASH(0x590678f369d0)
Jul 16 15:37:03 pve qmeventd[49081]: Content $pid:

Stop Guest:
Jul 16 15:38:22 pve qmeventd[49686]: Starting cleanup for 200
Jul 16 15:38:22 pve qmeventd[49686]: vm still running                   
Jul 16 15:38:22 pve qmeventd[49686]: Content $vmid: 200                 
Jul 16 15:38:22 pve qmeventd[49686]: Content $conf: HASH(0x5a0a2b3ec618)
Jul 16 15:38:22 pve qmeventd[49686]: Content $pid: 49267

Evtl. helfen die Info's, falls sich jemand die Mühe macht das weiter zu debuggen.

aaron · Jul 16, 2024

Nuffi said:
Jul 15 15:33:56 pve qmeventd[103595]: vm still running

Dann ist aber die Frage, wieso die VM noch läuft. Was mit den MDEVs zu tun hat. Ich kenn mich damit aber nicht gut genug aus. @dcsapak hast du evtl eine Idee wieso die VM nach 60 Sekunden noch laufen könnte?

Nuffi · Jul 16, 2024

aaron said:
Dann ist aber die Frage, wieso die VM noch läuft. Was mit den MDEVs zu tun hat. Ich kenn mich damit aber nicht gut genug aus. @dcsapak hast du evtl eine Idee wieso die VM nach 60 Sekunden noch laufen könnte?

Der Shutdownprozess wartet hier keine 60 Sekunden. Vom Herunterfahren im Gast bis zu der Meldung vergehen nur ca. 3 Sekunden.

aaron · Jul 17, 2024

kannst du bitte mal folgendes probieren?
Stoppe den qmeventd:

Code:

systemctl stop qmeventd.service

und starte ihn dann im Vordergrund, um die gesamte Debug Log zu sehen:

Code:

qmeventd -f -v /var/run/qmeventd.sock

Warte dann circa 10 Sekunden. Du wirst sehen, dass sich die laufenden VMs melden.
Dann fahre die VM vom Gast aus herunter. Der Output, der dabei entsteht, liefert uns hoffentlich mehr Hinweise, wieso der qmeventd schon reagiert, bevor die VM wirklich gestoppt ist.

Danach mit CTRL+C den qmeventd im Vordergrund stoppen und mit
systemctl start qmeventd.service
wieder regulär starten.

Nuffi · Jul 17, 2024

Danke für die Hilfe, hier ist der verbose Output:

Code:

root@pve:~# systemctl stop qmeventd.service
root@pve:~#
root@pve:~# qmeventd -f -v /var/run/qmeventd.sock
added new client, pid: 2931
pid2931: entering handle
pid2931: read 125 bytes
pid2931: got QMP handshake, assuming QEMU client
pid2931: assigned VMID: 200
pid2931: entering handle
pid2931: read 16 bytes
200: QMP handshake complete
pid2931: entering handle
pid2931: read 160 bytes
200: got QMP event: RTC_CHANGE
pid2931: entering handle
pid2931: read 161 bytes
200: got QMP event: RTC_CHANGE
pid2931: entering handle
pid2931: read 175 bytes
200: got QMP event: NIC_RX_FILTER_CHANGED
## BOOT FERTIG ##

pid2931: entering handle
pid2931: read 160 bytes
200: got QMP event: RTC_CHANGE
pid2931: entering handle
pid2931: read 138 bytes
200: got QMP event: SHUTDOWN
200: query-status
pid2931: entering handle
pid2931: read 81 bytes
200: got QMP event: STOP
pid2931: entering handle
pid2931: read 54 bytes
200: terminating client (pid 2931)
200: sending 'quit' via QMP
clearing forced cleanup backlog
pid2931: entering handle
pid2931: read 138 bytes
200: got QMP event: SHUTDOWN
200: event was after termination, ignoring
clearing forced cleanup backlog
pid2931: entering handle
pid2931: read 16 bytes
clearing forced cleanup backlog
pid2931: entering handle
read: Connection reset by peer
200: executing cleanup (graceful: 1, guest: 1)
removing 200 from forced cleanups
Starting cleanup for 200
Content $vmid: 200
Content $conf: HASH(0x61613cca4438)
Content $pid: 2931
vm still running

aaron · Jul 18, 2024

Wie lange ist denn der Qemu Prozess mit der $pid noch aktiv und in welchem State?

Code:

ps auxwf | grep {pid}

Nuffi · Jul 18, 2024

Im Journal kann man die Zeiten grob sehen, zwischen dem Abbruch des cleanup und dem tatsächlichen löschen des Scope liegen 2 Sekunden.
Was noch auffällt ist, das die durchgereichten Devices erst freigegeben werden, nachdem der Cleanup schon ausgestiegen ist.

Code:

...
Jul 18 22:32:35 pve kernel: fwpr200p0 (unregistering): left promiscuous mode
Jul 18 22:32:35 pve kernel: vmbr0: port 2(fwpr200p0) entered disabled state
Jul 18 22:32:35 pve qmeventd[2004]: pid10239: entering handle
Jul 18 22:32:35 pve qmeventd[2004]: pid10239: read 16 bytes
Jul 18 22:32:35 pve qmeventd[2004]: clearing forced cleanup backlog
Jul 18 22:32:35 pve qmeventd[2004]: pid10239: entering handle
Jul 18 22:32:35 pve qmeventd[2004]: read: Connection reset by peer
Jul 18 22:32:35 pve qmeventd[2004]: 200: executing cleanup (graceful: 1, guest: 1)
Jul 18 22:32:35 pve qmeventd[2004]: removing 200 from forced cleanups
Jul 18 22:32:35 pve kernel: usb 1-5: reset full-speed USB device number 4 using xhci_hcd
Jul 18 22:32:36 pve kernel: input: Microsoft Xbox Series S|X Controller as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5:1.0/input/in
put33
Jul 18 22:32:36 pve kernel: usb 1-12: reset full-speed USB device number 6 using xhci_hcd
Jul 18 22:32:36 pve qmeventd[11882]: Starting cleanup for 200
Jul 18 22:32:36 pve qmeventd[11882]: vm still running
Jul 18 22:32:36 pve qmeventd[11882]: Content $vmid: 200
Jul 18 22:32:36 pve qmeventd[11882]: Content $conf: HASH(0x56a6f2416f30)
Jul 18 22:32:36 pve qmeventd[11882]: Content $pid: 10239
Jul 18 22:32:36 pve kernel: usb 1-12: Warning! Unlikely big volume range (=4096), cval->res is probably wrong.
Jul 18 22:32:36 pve kernel: usb 1-12: [11] FU [Sidetone Playback Volume] ch = 1, val = 0/4096/1
Jul 18 22:32:36 pve kernel: input: Kingston HyperX 7.1 Audio Consumer Control as /devices/pci0000:00/0000:00:14.0/usb1/1-12/1-12:1.3/
0003:0951:16A4.0010/input/input34
Jul 18 22:32:36 pve kernel: input: Kingston HyperX 7.1 Audio as /devices/pci0000:00/0000:00:14.0/usb1/1-12/1-12:1.3/0003:0951:16A4.00
10/input/input35
Jul 18 22:32:36 pve kernel: input: Kingston HyperX 7.1 Audio as /devices/pci0000:00/0000:00:14.0/usb1/1-12/1-12:1.3/0003:0951:16A4.00
10/input/input36
Jul 18 22:32:36 pve kernel: hid-generic 0003:0951:16A4.0010: input,hiddev0,hidraw0: USB HID v1.11 Device [Kingston HyperX 7.1 Audio]
on usb-0000:00:14.0-12/input3
Jul 18 22:32:36 pve systemd[1]: Reached target sound.target - Sound Card.
Jul 18 22:32:36 pve systemd[3493]: Reached target sound.target - Sound Card.
Jul 18 22:32:36 pve kernel: usb 1-3: reset full-speed USB device number 3 using xhci_hcd
Jul 18 22:32:37 pve kernel: input: Logitech G502 HERO Gaming Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/0003:046D:C08
B.0011/input/input37
Jul 18 22:32:37 pve kernel: hid-generic 0003:046D:C08B.0011: input,hidraw1: USB HID v1.11 Mouse [Logitech G502 HERO Gaming Mouse] on
usb-0000:00:14.0-3/input0
Jul 18 22:32:37 pve kernel: input: Logitech G502 HERO Gaming Mouse Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.1/0003
:046D:C08B.0012/input/input38
Jul 18 22:32:37 pve kernel: hid-generic 0003:046D:C08B.0012: input,hiddev1,hidraw2: USB HID v1.11 Keyboard [Logitech G502 HERO Gaming
 Mouse] on usb-0000:00:14.0-3/input1
Jul 18 22:32:37 pve systemd-logind[2011]: Watching system buttons on /dev/input/event7 (Logitech G502 HERO Gaming Mouse Keyboard)
Jul 18 22:32:37 pve kernel: usb 1-2: reset low-speed USB device number 2 using xhci_hcd
Jul 18 22:32:37 pve kernel: input: HID 046a:010d as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/0003:046A:010D.0013/input/input
41
Jul 18 22:32:37 pve kernel: hid-generic 0003:046A:010D.0013: input,hidraw3: USB HID v1.11 Keyboard [HID 046a:010d] on usb-0000:00:14.
0-2/input0
Jul 18 22:32:37 pve kernel: input: HID 046a:010d as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.1/0003:046A:010D.0014/input/input
42
Jul 18 22:32:37 pve systemd-logind[2011]: Watching system buttons on /dev/input/event8 (HID 046a:010d)
Jul 18 22:32:37 pve kernel: hid-generic 0003:046A:010D.0014: input,hidraw4: USB HID v1.11 Device [HID 046a:010d] on usb-0000:00:14.0-
2/input1
Jul 18 22:32:37 pve systemd-logind[2011]: Watching system buttons on /dev/input/event9 (HID 046a:010d)
Jul 18 22:32:38 pve systemd[1]: 200.scope: Deactivated successfully.
Jul 18 22:32:38 pve systemd[1]: 200.scope: Consumed 1min 27.164s CPU time.

Search

Search

Hookscript wird nicht genutzt

Nuffi

New Member

aaron

Proxmox Staff Member

Nuffi

New Member

aaron

Proxmox Staff Member

Nuffi

New Member

Nuffi

New Member

aaron

Proxmox Staff Member

Nuffi

New Member

aaron

Proxmox Staff Member

Nuffi

New Member

Nuffi

New Member

Nuffi

New Member

aaron

Proxmox Staff Member

Nuffi

New Member

aaron

Proxmox Staff Member

Nuffi

New Member

aaron

Proxmox Staff Member

Nuffi

New Member