Am 09.03.22 um 14:38 schrieb Mark Schouten: > Hi, > > Ok. Funny enough, I suffered from this issue last night during maintenance… > But since I have not had this issue before, I had no snapshot… > > I guess the snapshot would need to have a state as well, right? So the > machine is ‘booted’ as it was. >
Not necessarily. It'd be enough if the issue can be reproduced by doing a cold boot, maybe some specific operation afterwards, then reboot. From there, it'd be very easy to create such a snapshot for further testing. > — > Mark Schouten, CTO > Tuxis B.V. > m...@tuxis.nl > > > >> On 9 Mar 2022, at 08:31, Fabian Ebner <f.eb...@proxmox.com> wrote: >> >> 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
