[pve-devel] [RFC qemu-server v2 32/32] command line: switch to blockdev starting with machine version 10.0

[DERUMIER, Alexandre]

-------- Message initial --------
De: Fiona Ebner <f.ebner at proxmox.com>
À: Proxmox VE development discussion <pve-devel at lists.proxmox.com>
Cc: "DERUMIER, Alexandre" <alexandre.derumier at groupe-cyllene.com>
Objet: Re: [pve-devel] [RFC qemu-server v2 32/32] command line: switch
to blockdev starting with machine version 10.0
Date: 23/06/2025 11:31:02

Am 23.06.25 um 11:12 schrieb DERUMIER, Alexandre via pve-devel:
> > > +        my $blockdev =
> > > PVE::QemuServer::Blockdev::generate_drive_blockdev($storecfg,
> > > $device, {});
> > > +        mon_cmd($vmid, 'blockdev-add', %$blockdev, timeout =>
> > > 60);
> > > +
> > > +        return 1;
> 
> should we handle error here ?  (I don't known if a blockdev-add can
> fail , and if it need 60s timeout like drive-add, as I think that the
> blockdev open is done in device-add)

Yes, we could remove the throttle group again if it fails.


>>qmp_blockdev_add() calls bds_tree_init() which calls bdrv_open(). So
>>I
>>think using 60 seconds here like for "drive_add" is a sensible
choice.

ah ok, indeed if the bdrv_open is done here (I was not sure), this make
sense


>>Note that "device_add" currently only uses the default timeout of 5
>>seconds. I'm not aware about reports about failure there directly. I
>>had
>>sent a patch to increase that a while ago [0] because of a report
>>with
>>"netdev_add". But probably would be good to take in too.

Never have seen problem of device_add, but yet, maybe with some os (we
look a t you windows ;), it's possible.