public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
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
>>>>
>>>
>>>
>>>
>>
> 
> 
> 




      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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal