From: Fabian Ebner <f.ebner@proxmox.com>
To: Mark Schouten <mark@tuxis.nl>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH kernel] Backport two io-wq fixes relevant for io_uring
Date: Thu, 10 Mar 2022 08:36:01 +0100 [thread overview]
Message-ID: <84a8516f-4aa2-f111-339c-b8bc2840d15f@proxmox.com> (raw)
In-Reply-To: <9C5B831F-C706-4834-B38B-D5BEEE5B32DA@tuxis.nl>
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.
> mark@tuxis.nl
>
>
>
>> On 9 Mar 2022, at 08:31, Fabian Ebner <f.ebner@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.
>>> mark@tuxis.nl
>>>
>>>
>>>
>>>> On 8 Mar 2022, at 10:12, Fabian Ebner <f.ebner@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.
>>>>> mark@tuxis.nl
>>>>
>>>
>>>
>>>
>>
>
>
>
prev parent reply other threads:[~2022-03-10 7:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-23 11:59 Fabian Ebner
2021-11-23 11:59 ` [pve-devel] [RFC] Changes made for backporting Fabian Ebner
2021-11-23 14:15 ` [pve-devel] applied: [PATCH kernel] Backport two io-wq fixes relevant for io_uring Thomas Lamprecht
[not found] ` <5CC63593-424B-4439-93FB-BFFD6B087952@tuxis.nl>
2022-03-08 9:12 ` [pve-devel] " Fabian Ebner
[not found] ` <E1D57A66-615B-4CA1-874C-ACD2B97B507C@tuxis.nl>
2022-03-09 7:31 ` Fabian Ebner
[not found] ` <9C5B831F-C706-4834-B38B-D5BEEE5B32DA@tuxis.nl>
2022-03-10 7:36 ` Fabian Ebner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=84a8516f-4aa2-f111-339c-b8bc2840d15f@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=mark@tuxis.nl \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal