Eric Blake writes:
> On Thu, Aug 29, 2024 at 01:56:43PM GMT, Markus Armbruster wrote:
>> Daniil Tatianin writes:
>>
>> > The "reconnect" option only allows to specify the time in seconds,
>> > which is way too long for certain workflows.
>
> ...
>> > @@ -287,7 +292,8 @@
>> > '*teln
On Thu, Aug 29, 2024 at 01:56:43PM GMT, Markus Armbruster wrote:
> Daniil Tatianin writes:
>
> > The "reconnect" option only allows to specify the time in seconds,
> > which is way too long for certain workflows.
...
> > @@ -287,7 +292,8 @@
> > '*telnet': 'bool',
> > '*
On Thu, Aug 29, 2024 at 13:56:43 +0200, Markus Armbruster wrote:
> Daniil Tatianin writes:
[...]
So firstly, libvirt models the timeout in the XML in seconds for now so
making use of this will require some XML design plumbing making use of
it if there'll be any users wanting it.
When libvirt wo
On 8/29/24 2:56 PM, Markus Armbruster wrote:
Daniil Tatianin writes:
The "reconnect" option only allows to specify the time in seconds,
which is way too long for certain workflows.
We have a lightweight disk backend server, which takes about 20ms to
live update, but due to this limitation in
Daniil Tatianin writes:
> The "reconnect" option only allows to specify the time in seconds,
> which is way too long for certain workflows.
>
> We have a lightweight disk backend server, which takes about 20ms to
> live update, but due to this limitation in QEMU, previously the guest
> disk contr
The "reconnect" option only allows to specify the time in seconds,
which is way too long for certain workflows.
We have a lightweight disk backend server, which takes about 20ms to
live update, but due to this limitation in QEMU, previously the guest
disk controller would hang for one second becau
