Am 10.08.2020 um 16:52 hat Zhenyu Ye geschrieben:
> Before doing qmp actions, we need to lock the qemu_global_mutex,
> so the qmp actions should not take too long time.
>
> Unfortunately, some qmp actions need to acquire aio context and
> this may take a long time. The vm will soft lockup if
On 8/10/20 5:11 PM, Max Reitz wrote:
(Note: When submitting a patch series with multiple patches, our
guidelines require a cover letter:
https://wiki.qemu.org/Contribute/SubmitAPatch#Include_a_meaningful_cover_letter
But not too important now.)
Sorry, remembered for next time. Thanks for
(Note: When submitting a patch series with multiple patches, our
guidelines require a cover letter:
https://wiki.qemu.org/Contribute/SubmitAPatch#Include_a_meaningful_cover_letter
But not too important now.)
On 10.08.20 11:55, Stefan Reiter wrote:
> Start a VM with a 4097 byte image attached,
On 10.08.20 11:55, Stefan Reiter wrote:
> Since commit 42ac214406e0 (block/block-copy: refactor task creation)
> block_copy_task_create calculates the area to be copied via
> bdrv_dirty_bitmap_next_dirty_area, but that can return an unaligned byte
> count if the image's last cluster end is not
10.08.2020 17:20, Eric Blake wrote:
On 8/10/20 7:35 AM, Denis V. Lunev wrote:
The problem this patch is trying to address is libguestfs behavior on the
appliance startup. It starts supporting to use root=UUID definition in
the kernel command line of its root filesystem using
file --
Currently we only have the aio_context_acquire() to take the
ownership of the AioContext. If the mutex is locked by other
threads, this function will wait util the mutex is released.
Sometimes we may want to get some return values after waiting
for some time. So introduce
Before doing qmp actions, we need to lock the qemu_global_mutex,
so the qmp actions should not take too long time.
Unfortunately, some qmp actions need to acquire aio context and
this may take a long time. So replace aio_context_acquire()
by aio_context_acquire_timeout() and return ETIMEDOUT if
Before doing qmp actions, we need to lock the qemu_global_mutex,
so the qmp actions should not take too long time.
Unfortunately, some qmp actions need to acquire aio context and
this may take a long time. The vm will soft lockup if this time
is too long.
So add a timeout mechanism while doing
On 8/10/20 5:40 PM, Kevin Wolf wrote:
> Am 10.08.2020 um 16:02 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> 10.08.2020 15:35, Denis V. Lunev wrote:
>>> The problem this patch is trying to address is libguestfs behavior on the
>>> appliance startup. It starts supporting to use root=UUID
Am 10.08.2020 um 16:02 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 10.08.2020 15:35, Denis V. Lunev wrote:
> > The problem this patch is trying to address is libguestfs behavior on the
> > appliance startup. It starts supporting to use root=UUID definition in
> > the kernel command line of its
On 8/10/20 7:35 AM, Denis V. Lunev wrote:
The problem this patch is trying to address is libguestfs behavior on the
appliance startup. It starts supporting to use root=UUID definition in
the kernel command line of its root filesystem using
file -- /usr/lib64/guestfs/appliance/root
This
10.08.2020 15:35, Denis V. Lunev wrote:
The problem this patch is trying to address is libguestfs behavior on the
appliance startup. It starts supporting to use root=UUID definition in
the kernel command line of its root filesystem using
file -- /usr/lib64/guestfs/appliance/root
This works
Am 07.08.2020 um 15:29 hat Markus Armbruster geschrieben:
> This is just a sketch. It needs comments and a real commit message.
>
> As is, it goes on top of Kevin's series. It is meant to be squashed
> into PATCH 06.
>
> Signed-off-by: Markus Armbruster
> ---
> include/qemu/coroutine.h |
On 8/10/20 3:52 PM, Richard W.M. Jones wrote:
> On Mon, Aug 10, 2020 at 03:35:55PM +0300, Denis V. Lunev wrote:
>> The problem this patch is trying to address is libguestfs behavior on the
>> appliance startup. It starts supporting to use root=UUID definition in
>> the kernel command line of its
On Mon, Aug 10, 2020 at 03:35:55PM +0300, Denis V. Lunev wrote:
> The problem this patch is trying to address is libguestfs behavior on the
> appliance startup. It starts supporting to use root=UUID definition in
> the kernel command line of its root filesystem using
> file --
The problem this patch is trying to address is libguestfs behavior on the
appliance startup. It starts supporting to use root=UUID definition in
the kernel command line of its root filesystem using
file -- /usr/lib64/guestfs/appliance/root
This works fine with RAW image, but we are using
Am 07.08.2020 um 15:27 hat Markus Armbruster geschrieben:
> This is just a sketch. It's incomplete, needs comments and a real
> commit message.
>
> Support for "[PATCH v6 09/12] hmp: Add support for coroutine command
> handlers" is missing. Marked FIXME.
>
> As is, it goes on top of Kevin's
10.08.2020 11:12, Max Reitz wrote:
On 07.08.20 12:29, Vladimir Sementsov-Ogievskiy wrote:
16.07.2020 17:59, Max Reitz wrote:
On 10.07.20 19:41, Andrey Shinkevich wrote:
On 10.07.2020 18:24, Max Reitz wrote:
On 09.07.20 16:52, Andrey Shinkevich wrote:
On 25.06.2020 18:21, Max Reitz wrote:
Right now BlockAcctStats is always reside on BlockBackend. This structure
is not used in any other place. Thus we are able to create a converter
from one pointer to another.
Signed-off-by: Denis V. Lunev
Reviewed-by: Vladimir Sementsov-Ogievskiy
CC: Stefan Hajnoczi
CC: Kevin Wolf
CC: Max
Latency threshold is set to 10 seconds following guest request timeout
on legacy storage controller.
Signed-off-by: Denis V. Lunev
CC: Vladimir Sementsov-Ogievskiy
CC: Stefan Hajnoczi
CC: Kevin Wolf
CC: Max Reitz
---
blockdev.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
There are severe delays with IO requests processing if QEMU is running in
virtual machine or over software defined storage. Such delays potentially
results in unpredictable guest behavior. For example, guests over IDE or
SATA drive could remount filesystem read-only if write is performed
longer
There are severe delays with IO requests processing if QEMU is running in
virtual machine or over software defined storage. Such delays potentially
results in unpredictable guest behavior. For example, guests over IDE or
SATA drive could remount filesystem read-only if write is performed
longer
Start a VM with a 4097 byte image attached, add a 4096 byte granularity
dirty bitmap, mark it dirty, and then do a backup.
This used to run into an assert and fail, check that it works as
expected and also check the created image to ensure that misaligned
backups in general work correctly.
Since commit 42ac214406e0 (block/block-copy: refactor task creation)
block_copy_task_create calculates the area to be copied via
bdrv_dirty_bitmap_next_dirty_area, but that can return an unaligned byte
count if the image's last cluster end is not aligned to the bitmap's
granularity.
Always
On 07.08.20 12:29, Vladimir Sementsov-Ogievskiy wrote:
> 16.07.2020 17:59, Max Reitz wrote:
>> On 10.07.20 19:41, Andrey Shinkevich wrote:
>>> On 10.07.2020 18:24, Max Reitz wrote:
On 09.07.20 16:52, Andrey Shinkevich wrote:
> On 25.06.2020 18:21, Max Reitz wrote:
>> Because of the
25 matches
Mail list logo
