Re: [PATCH v5 4/6] vhost-user-blk: make inflight-migration prop mutable

Alexandr Moshkov <[email protected]>
Newsgroups gmane.comp.emulators.qemu,gmane.comp.emulators.qemu.block
Message-ID <[email protected]>
On 7/29/26 15:14, Michael S. Tsirkin wrote:
> On Wed, Jul 29, 2026 at 03:09:57PM +0500, Alexandr Moshkov wrote:
>> On 7/29/26 14:32, Michael S. Tsirkin wrote:
>>
>>      On Tue, Jul 28, 2026 at 03:08:39PM +0500, Alexandr Moshkov wrote:
>>
>>          When migrating from a QEMU version that supports inflight-migration to
>>          an older one that does not, there is no way to disable the feature at
>>          runtime — the VM must be stopped and reconfigured. This is impractical
>>          in production environments.
>>
>>          Make the inflight-migration property mutable after device realization
>>          so it can be toggled via qom-set without restarting the VM.
>>
>>          Acked-by: Raphael Norwitz <[email protected]>
>>          Signed-off-by: Alexandr Moshkov <[email protected]>
>>
>>
>>
>>      I think I am beginning to understand.
>>
>>
>>      You are running qemu with inflight-migration on and want to migrate
>>      to qemu without inflight-migration at all.
>>
>>
>>      Since it is guest transparent you could retrofit it like this.
>>
>>      My question is why is it worth it, we do not normally support
>>      migrating between qemu versions with different command lines.
>>
>> I think you right. Maybe I've been focusing too much on the ability to migrate
>> between versions of qemu with and without inflight migration.
>>
>> This series allows to turn off and on the inflight-migration feature at runtime
>> without recreating the VM (it was the only way to turn off the feature, since
>> the protocol feature could no longer be turned off, after initialization with
>> the backend). This is more important feature, and it leads to the fact that
>> this feature allows to migrate between different versions of qemu (with and
>> without inflight-migration support).
>>
>>      
>>
>>          ---
>>           hw/block/vhost-user-blk.c | 10 ++++++++--
>>           1 file changed, 8 insertions(+), 2 deletions(-)
>>
>>          diff --git a/hw/block/vhost-user-blk.c b/hw/block/vhost-user-blk.c
>>          index e3b873af7c..650c004bde 100644
>>          --- a/hw/block/vhost-user-blk.c
>>          +++ b/hw/block/vhost-user-blk.c
>>          @@ -619,6 +619,8 @@ static const VMStateDescription vmstate_vhost_user_blk = {
>>               }
>>           };
>>
>>          +static PropertyInfo vhost_user_blk_inflight_migration_prop;
>>          +
>>           static const Property vhost_user_blk_properties[] = {
>>               DEFINE_PROP_CHR("chardev", VHostUserBlk, chardev),
>>               DEFINE_PROP_UINT16("num-queues", VHostUserBlk, num_queues,
>>          @@ -632,8 +634,9 @@ static const Property vhost_user_blk_properties[] = {
>>                                 VIRTIO_BLK_F_WRITE_ZEROES, true),
>>               DEFINE_PROP_BOOL("skip-get-vring-base-on-force-shutdown", VHostUserBlk,
>>                                skip_get_vring_base_on_force_shutdown, false),
>>          -    DEFINE_PROP_BOOL("inflight-migration", VHostUserBlk,
>>          -                     inflight_migration, false),
>>          +    DEFINE_PROP("inflight-migration", VHostUserBlk, inflight_migration,
>>          +                vhost_user_blk_inflight_migration_prop, bool,
>>          +                .set_default = true, .defval.u = false),
>>           };
>>
>>           static void vhost_user_blk_class_init(ObjectClass *klass, const void *data)
>>          @@ -665,6 +668,9 @@ static const TypeInfo vhost_user_blk_info = {
>>
>>           static void virtio_register_types(void)
>>           {
>>          +    vhost_user_blk_inflight_migration_prop = qdev_prop_bool;
>>          +    vhost_user_blk_inflight_migration_prop.realized_set_allowed = true;
>>          +
>>               type_register_static(&vhost_user_blk_info);
>>           }
>>
>>      So then,  for example, let us say I paused the VM, then set the flag,
>>      now inflight is on but GET_BASE did not drain it?
>>
>> If I understood the question correctly, this is valid behavior. Before
>> migration QEMU check protocol features to understand does the backend support
>> inflight migration. If it does, after that QEMU migrate inflight buffer to
>> other VM. If it's not, return error before migration started.
>
> I apologise i reverted the logic in the question.
>
>
> I start vm and inflight is on.
> I stop vm get base does not drain.

In case of VM stop, backend wait to drain all requests. Ability to 
perform drain or not available only during migration by skip_drain 
variable in vhost_user_blk_stop().
skip_drain true only if inflight_migration is on and runstate is 
FINISH_MIGRATION.

> i turn inflight off.
> now it looks like it will happily migrate?

So in this case, when vm migrated with inflight off, it will leads to 
using GET_VRING_BASE message, that wait all requests to be drained.

>
>>          --
>>          2.34.1
>>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.