Am 08.03.22 um 17:19 schrieb Mark Schouten: > Hi, > > So should I try and find someone who is able to reproduce this with a > test-machine and is able to give you remote access to debug? Would that help? >
It would certainly increase the likelihood of finding the issue. Since it only happens on 7.x, it's likely a regression. Ideally, there needs to be a snapshot of a problematic VM before the reboot, so that it can be quickly tested against with e.g. different builds of QEMU/kernel. Providing such a VM with snapshot state would of course be an alternative to remote access. > — > Mark Schouten, CTO > Tuxis B.V. > m...@tuxis.nl > > > >> On 8 Mar 2022, at 10:12, Fabian Ebner <f.eb...@proxmox.com> wrote: >> >> Am 07.03.22 um 15:51 schrieb Mark Schouten: >>> Hi, >>> >>> Sorry for getting back on this thread after a few months, but is the >>> Windows-case mentioned here the case that is discussed in this forum-thread: >>> https://forum.proxmox.com/threads/windows-vms-stuck-on-boot-after-proxmox-upgrade-to-7-0.100744/page-3 >>> >>> <https://forum.proxmox.com/threads/windows-vms-stuck-on-boot-after-proxmox-upgrade-to-7-0.100744/page-3> >>> >>> ? >> >> Hi, >> the symptoms there sound rather different. The issue addressed by this >> patch was about a QEMU process getting completely stuck on I/O while the >> VM was live already. "completely" meant that e.g. connecting for the >> display also would fail and there would be messages like >> >> VM 182 qmp command failed - VM 182 qmp command 'query-proxmox-support' >> failed - unable to connect to VM 182 qmp socket - timeout after 31 retries >> >> in the syslog. The issue described in the forum thread reads like it >> happens only upon reboot from inside the guest and nobody mentioned >> messages like the above. >> >>> >>> If so, should this be investigated further or are there other issues? I >>> have personally not had the issue mentioned in the forum, but quite a few >>> people seem to be suffering from issues with Windows VMs, which is >>> currently holding us back from upgrading from 6.x to 7.x on a whole bunch >>> of customer clusters. >> >> I also haven't seen the issue myself yet and haven't heard from any >> colleagues either. Without a reproducer, it's very difficult to debug. >> >>> >>> Thanks, >>> >>> — >>> Mark Schouten, CTO >>> Tuxis B.V. >>> m...@tuxis.nl >> > > > _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel