Hey everyone,

I finally got around to open the same bug in the Debian BTS:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958926

Also, the QA suite now passes on Ubuntu Focal with the latest qemu
packages. I have some issues with the nightly builds repository but as soon
as that is fixed, packages for focal will be provided as well (and I will
also configure a nightly build for focal).

Cheers,
Rudi

On Fri, Apr 17, 2020 at 12:17 PM Rudolph Bott <[email protected]> wrote:

> Hey everyone,
>
> quick update - the bug has presumably been fixed on Ubuntu. I'll check
> this later. I will try to figure out if Debian needs to be informed
> separately or if there is some information flow between Ubuntu / Debian
> package maintainers.
>
> More information is available here:
> https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1872107
>
> Cheers,
> Rudi
>
> On Sat, Apr 11, 2020 at 2:47 PM Rudolph Bott <[email protected]> wrote:
>
>> Hey everyone,
>>
>> I have opened a bug at launchpad for the qemu-kvm package in Ubuntu -
>> let's see what happens there:
>>
>> https://bugs.launchpad.net/qemu-kvm/+bug/1872107
>>
>> However, we still need an intermediate solution to continue testing on
>> Debian Bullseye and/or Ubuntu Focal Fossa. I took a look at all the "info
>> *" queries which the QEMU monitor socket provides but none of them seem to
>> be able to indicate that the instance is currently in an early booting
>> state. That means for now in regards to the QA suite the only options left
>> are either swapping the order of tests or adding a short sleep time between
>> them. I will open a PR for that soon.
>>
>> However, even with a solution for the QA suite this still means that
>> currently any live migration on Bullseye or Focal would crash if there is a
>> reboot going on within the VM (which depending on the amount of people
>> using/administrating your cluster and the instances running on it is a more
>> or less likely thing to happen).
>>
>> Looking forward to any suggestions here.
>>
>> Cheers,
>> Rudi
>>
>> On Mon, Apr 6, 2020 at 12:39 PM Sascha Lucas <[email protected]> wrote:
>>
>>> Hi Rudi,
>>>
>>> On Sun, 5 Apr 2020, Rudolph Bott wrote:
>>>
>>> > I entirely forgot about the QEMU log files. Yes, we can see an error
>>> > message from the crashing QEMU process:
>>> >
>>> > qemu-system-x86_64:
>>> /build/qemu-oknQD6/qemu-4.2/accel/kvm/kvm-all.c:653:
>>> > kvm_log_clear_one_slot: Assertion `mem->dirty_bmap' failed.
>>>
>>> Nice finding. Well done!
>>>
>>> > It seems that it's related to starting a migration while the QEMU
>>> process
>>> > (or rather: the VM inside) is still in the boot phase. The fix for
>>> this is
>>> > already upstream:
>>> >
>>> >
>>> https://github.com/qemu/qemu/commit/9b3a31c745b61758aaa5466a3a9fc0526d409188
>>> >
>>> > However, it seems it is only in for the next QEMU 5 release. I think we
>>> > should open a Debian Bug for this (however, after quickly reading
>>> through
>>> > the guide I am not a 100% sure I understood how to open a bug for QEMU
>>> in
>>> > bullseye). Maybe the fix can be backported.
>>>
>>> I'm also unsure about bullseye. Once it has package freeze, QEMU 5 might
>>> be included. Don't know if someone is willing to backport patches here.
>>> However Ubuntu/focal is shipping with QEMU 4.2. Maybe it's worth to open
>>> an issue there?
>>>
>>> > Any ideas how to work around this issue in the QA suite for now? Swap
>>> > failover / migration tests?
>>>
>>> Does swapping the tests help? ATM I seen no other options besides
>>> inserting sleeps/delays.
>>>
>>> > But from what I understand, this can also be an issue when
>>> > someone triggers a live migration through ganeti while the VM is in a
>>> > rebooting state internally. That again is something which might hit
>>> > people in production.
>>>
>>> I understand it in the same way, so this bug should be fixed.
>>>
>>> Thanks, Sascha.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ganeti-devel" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/ganeti-devel/alpine.DEB.2.20.2004061223490.5424%40ivy.loc
>>> .
>>>
>>
>>
>> --
>>  Rudolph Bott - [email protected]
>>  Telefon: +49 (0)211-63 55 56-41
>>  Telefax: +49 (0)211-63 55 55-22
>>
>>  sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf
>>  HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois
>>  Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391
>>
>>  www.sipgate.de - www.sipgate.co.uk
>>
>
>
> --
>  Rudolph Bott - [email protected]
>  Telefon: +49 (0)211-63 55 56-41
>  Telefax: +49 (0)211-63 55 55-22
>
>  sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf
>  HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois
>  Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391
>
>  www.sipgate.de - www.sipgate.co.uk
>


-- 
 Rudolph Bott - [email protected]
 Telefon: +49 (0)211-63 55 56-41
 Telefax: +49 (0)211-63 55 55-22

 sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf
 HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois
 Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391

 www.sipgate.de - www.sipgate.co.uk

-- 
You received this message because you are subscribed to the Google Groups 
"ganeti-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ganeti-devel/CAPG4N%3DZ%2B%2BncM_r6TQw0KsEfmEFohEiPqSYwbebwASot6M2kARQ%40mail.gmail.com.

Reply via email to