I managed to upgrade to qemu 4.1 on a test KVM host and I can confirm I can't
repro the issue in this version.
Great news that is fixed in 4.1.
Thanks everyone for your inputs and the fast replies.
Kind regards,
Fernando
On vie, oct 25, 2019 at 12:28 PM, Fernando Casas Schössow
Thanks for the reply Kevin.
I will do my best to upgrade to 4.1, test again and report back if this is
fixed or not in that version.
Hopefully it is.
Fernando
On vie, oct 25, 2019 at 12:07 PM, Kevin Wolf wrote:
Am 23.10.2019 um 19:28 hat Fernando Casas Schössow geschrieben:
Hi John, Thanks
BTW just to be clear, qemu is crashing in this scenario *only* if
iothread is enabled for the guest.
Without iothread enabled the operation is completed without any
problems.
On jue, oct 24, 2019 at 11:07 PM, Fernando Casas Schössow
wrote:
> Today I updated to qemu 4.0.1 since this was
core dump for analysis if needed.
While waiting for replies I will check if I can upgrade to qemu 4.1.0,
try to repro and provide the results.
Thanks.
Fernando
On mié, oct 23, 2019 at 7:57 PM, Fernando Casas Schössow
wrote:
> In virsh I would do this while the guest is running:
>
>
9 at 7:33 PM, John Snow wrote:
On 10/23/19 1:28 PM, Fernando Casas Schössow wrote:
Hi John, Thanks for looking into this. I can quickly repro the problem with
qemu 4.0 binary with debugging symbols enabled as I have it available already.
Doing the same with qemu 4.1 or development head may be too muc
worth it to try with 4.0 first and get the strack trace or it will not
help and the only way to go is with 4.1 (or dev)?
Thanks,
Fernando
On mié, oct 23, 2019 at 5:34 PM, John Snow wrote:
On 10/18/19 5:41 PM, Fernando Casas Schössow wrote:
Hi,
Hi! Thanks for the report.
Today while working wit
Hi,
Today while working with two different Windows Server 2012 R2 guests I
found that when I try to attach an ISO file to a SCSI CD-ROM device
through libvirt (virsh or virt-manager) while the guest is running,
qemu crashes and the following message is logged:
Assertion failed: blk_get_aio_con
Hi,
Today while working with two different Windows Server 2012 R2 guests I found
that when I try to attach an ISO file to a SCSI CD-ROM device through libvirt
(virsh or virt-manager) while the guest is running, qemu crashes and the
following message is logged:
Assertion failed: blk_get_aio_con
in to everyone that helped identifying and fixing this issue. Great
work.
Cheers,
Fer
On jue, mar 7, 2019 at 8:14 AM, Fernando Casas Schössow
wrote:
After two weeks of running the new QEMU package everything is fine.
Moreover I migrated the rest of the guests (both Windows and Linux) to
virtio-scs
After two weeks of running the new QEMU package everything is fine.
Moreover I migrated the rest of the guests (both Windows and Linux) to
virtio-scsi and no issues so far.
I will monitor for another week but this issue seems pretty much fixed!
Kudos to each and everyone of you that helped findin
Just wanted to share a small update on the situation after updating QEMU to the
new Alpine package patched with Natanael's patch.
So far so good, moreover I switched a few other guests from SATA to VirtIO SCSI
and after two days no issues.
Unless I find any problem I will report back with an upda
Ok, the new package is deployed.
I stopped and started the test guest so it will use the new QEMU binary.
Will monitor and report back.
On lun, feb 25, 2019 at 2:32 PM, Fernando Casas Schössow
wrote:
Thanks Natanael. Is the new package ready?
I will update as soon as the package is available
Thanks Natanael. Is the new package ready?
I will update as soon as the package is available, try to repro and report back.
Thanks everyone for looking into this!
On lun, feb 25, 2019 at 2:25 PM, Natanael Copa wrote:
On Mon, 25 Feb 2019 13:06:16 + Peter Maydell
mailto:peter.mayd...@linaro.
I’m running the test guest on another host for the last three days and so far
so good.
Yet because of the nature of this bug/issue it can take a few hours or a few
days more to fail. The failure is unpredictable.
Does it make sense to continue running the guest on this different host to try
to
rnando Casas Schössow
mailto:casasferna...@outlook.com>> wrote: I have
CCed Natanael Copa, qemu package maintainer in Alpine Linux. Fernando: Can you
confirm that the bug occurs with an unmodified Alpine Linux qemu binary?
I wonder exactly which binary it is. What arcitecture (x86 or x86_
Fernando
On vie, feb 22, 2019 at 3:55 PM, Paolo Bonzini wrote:
On 22/02/19 15:43, Fernando Casas Schössow wrote:
Hi all, Indeed I can confirm this issue occurs with the stock, unmodified QEMU
binary provided with Alpine since at least Alpine 3.6 up to 3.9. Is there any
compiler flag I ca
my iPhone
> On 22 Feb 2019, at 15:04, Stefan Hajnoczi wrote:
>
> On Fri, Feb 22, 2019 at 12:57 PM Fernando Casas Schössow
> wrote:
>
> I have CCed Natanael Copa, qemu package maintainer in Alpine Linux.
>
> Fernando: Can you confirm that the bug occurs with an unmodi
+, Fernando Casas Schössow wrote:
Regarding the dumps I have three of them including guest memory, 2 for
virtio-scsi, 1 for virtio-blk, in case a comparison may help to confirm which
is the proble.) I can upload them to a server you indicate me or I can also put
them on a server so you can
lping with this!
Kind regards,
Fernando
On mié, feb 20, 2019 at 6:53 PM, Paolo Bonzini wrote:
On 20/02/19 17:58, Stefan Hajnoczi wrote:
On Mon, Feb 18, 2019 at 07:21:25AM +, Fernando Casas Schössow wrote:
It took a few days but last night the problem was reproduced. This is the
informati
s.
On lun, feb 18, 2019 at 8:21 AM, Fernando Casas Schössow
wrote:
It took a few days but last night the problem was reproduced.
This is the information from the log:
vdev 0x55f261d940f0 ("virtio-blk")
vq 0x55f261d9ee40 (idx 0)
inuse 128 vring.num 128
old_shadow_avail_idx 58874 last_avail
It took a few days but last night the problem was reproduced.
This is the information from the log:
vdev 0x55f261d940f0 ("virtio-blk")
vq 0x55f261d9ee40 (idx 0)
inuse 128 vring.num 128
old_shadow_avail_idx 58874 last_avail_idx 58625 avail_idx 58874
avail 0x3d87a800 avail_idx (cache bypassed) 58625
qemu dumps as I
understood you will want to look at both (qemu dump and guest memory dump).
I will reply to this thread once I have any news.
Kind regards.
Fernando
On lun, feb 11, 2019 at 4:17 AM, Stefan Hajnoczi wrote:
On Wed, Feb 06, 2019 at 04:47:19PM +0000, Fernando Casas Schössow wrote:
I
on forward
and find the cause of this issue.
Thanks.
On mié, feb 6, 2019 at 8:15 AM, Fernando Casas Schössow
wrote:
I can now confirm that the same happens with virtio-blk and virtio-scsi.
Please find below the qemu log enhanced with the new information added by the
patch provided by Stefan:
vdev
2552Z qemu-system-x86_64: Virtqueue size exceeded
I just changed the disk back to virtio-scsi so I can repro this again with the
patched qemu and report back.
Thanks.
On lun, feb 4, 2019 at 8:24 AM, Fernando Casas Schössow
wrote:
I can test again with qemu 3.1 but with previous versions y
I can test again with qemu 3.1 but with previous versions yes, it was happening
the same with both virtio-blk and virtio-scsi.
For 3.1 I can confirm it happens for virtio-scsi (already tested it) and I can
test with virtio-blk again if that will add value to the investigation.
Also I'm attaching
31, 2019 at 11:32:32AM +, Fernando Casas Schössow wrote:
Sorry for resurrecting this thread after so long but I just upgraded the host
to Qemu 3.1 and libvirt 4.10 and I'm still facing this problem. At the moment I
cannot use virtio disks (virtio-blk nor virtio-scsi) with my guests in
.
It's really frustrating that after all this time I couldn't find the cause for
this issue so any ideas are welcome.
Thanks.
Fernando
____
From: Fernando Casas Schössow
Sent: Saturday, June 24, 2017 10:34 AM
To: Ladi Prosek
Cc: qemu-devel@nongnu.
x27;m more than willing to share them.
Thanks in advance.
Fernando
On jue, oct 18, 2018 at 3:40 PM, Fernando Casas Schössow
wrote:
Hi Kevin,
Not at the moment. This is a production system and pretty much up to date but
can't upgrade to 3.0 yet.
If the dump can be of any use, I can upload it
5 hat Fernando Casas Schössow geschrieben:
I hope this email finds you well and I apologize in advance for resurrecting
this thread. I'm currently running on qemu 2.12.1 and I'm still having this
issue every few days but now I managed to get a core dump generated (without
including t
ando Casas Schössow
Cc: qemu-devel; qemu-bl...@nongnu.org; Jeff Cody
Subject: Re: [Qemu-devel] qemu process crash: Assertion failed:
QLIST_EMPTY(&bs->tracked_requests)
On Wed, Dec 13, 2017 at 03:33:01PM +0000, Fernando Casas Schössow wrote:
> Maybe I’m missing something here but, if I r
debug info. :(
But I’m not 100% sure at the moment.
Sent from my iPhone
On 13 Dec 2017, at 12:23, Stefan Hajnoczi
mailto:stefa...@gmail.com>> wrote:
On Mon, Dec 11, 2017 at 01:42:38PM +, Fernando Casas Schössow wrote:
Hello Stefan,
Thanks for your reply.
Fortunately I didn’t have the p
.
Thanks.
Fer
Sent from my iPhone
On 11 Dec 2017, at 12:56, Stefan Hajnoczi
mailto:stefa...@gmail.com>> wrote:
On Thu, Dec 07, 2017 at 10:18:52AM +, Fernando Casas Schössow wrote:
Hi there,
Last night while doing a backup of a guest using the live snapshot mechanism
the qemu proce
Hi there,
Last night while doing a backup of a guest using the live snapshot mechanism
the qemu process for the guest seem to had crashed.
The snapshot succeeded then the backup of the VM disk had place and also
succeeded but the commit to the original disk after the backup seem to have
faile
,
Fer
On vie, jun 23, 2017 at 8:29 , Fernando Casas Schössow
wrote:
Hi Ladi,
Small update. Memtest86+ was running on the host for more than 54 hours. 8
passes were completed and no memory errors found. For now I think we can assume
that the host memory is ok.
I just started all the guests on
debugger and let you know.
Thanks.
Fer
On jue, jun 22, 2017 at 9:43 , Ladi Prosek wrote:
Hi Fernando, On Wed, Jun 21, 2017 at 2:19 PM, Fernando Casas Schössow
mailto:casasferna...@hotmail.com>> wrote:
Hi Ladi, Sorry for the delay in my reply. I will leave the host kernel alone
for no
Hi Ladi,
Sorry for the delay in my reply.
I will leave the host kernel alone for now then.
For the last 15 hours or so I'm running memtest86+ on the host. So far so good.
Two passes no errors so far. I will try to leave it running for at least
another 24hr and report back the results. Hopefully
, the host is running on ECC memory.
Thanks for all your help.
Fer.
On mar, jun 20, 2017 at 7:59 , Ladi Prosek wrote:
Hi Fernando, On Tue, Jun 20, 2017 at 12:10 AM, Fernando Casas Schössow
mailto:casasferna...@hotmail.com>> wrote:
Hi Ladi, Today two guests failed again at different times
e:
On Fri, Jun 16, 2017 at 12:11 PM, Fernando Casas Schössow
mailto:casasferna...@hotmail.com>> wrote:
Hi Ladi, Thanks a lot for looking into this and replying. I will do my best to
rebuild and deploy Alpine's qemu packages with this patch included but not sure
its feasible yet. In any
Hi Ladi,
Thanks a lot for looking into this and replying.
I will do my best to rebuild and deploy Alpine's qemu packages with this patch
included but not sure its feasible yet.
In any case, would it be possible to have this patch included in the next qemu
release?
The current error message is he
Hi there,
I recently migrated a Hyper-V host to qemu/kvm runing on Alpine Linux 3.6.1
(kernel 4.9.30 -with grsec patches- and qemu 2.8.1).
Almost on daily basis at least one of the guests is showing the following error
in the log and the it needs to be terminated and restarted to recover it:
q
40 matches
Mail list logo
