On 9/17/24 09:20, Andreas Neufert via pve-devel wrote:
Hi Proxmox Dev team,
Hi,
Tim Marx mentioned that you have some insights and change wishes for the Veeam
backup processing and that we should reach out to this list. We would be happy
to get this feedback here to be able to address it in our code or join a call
if this helps.
Thanks for reaching out!
During (very basic & short) testing, i discovered a few things that are problematic from our point
of view:
* During backup, there is often a longer running connection open to our QMP
socket of running VMs
(/var/run/qemu-server/XXXX.qmp, where XXXX is the vmid). This blocks our
management stack from
doing certain tasks, like start/stop (probably does not matter during backup)
but also
things like the VNC console, etc.
a better way would be to close the connections as soon as possible instead of
keeping them
open. (Alternatively using our API/CLI could also be done, but I don't know
what
exact QMP commands you're running)
if you absolutely need a longer running socket, please open a bug report on
https://bugzilla.proxmox.com so we can discuss and track that there, how we
could make
a socket available that is not used by our stack
* Another thing that I noticed was that it's not really visible if a backup is
running
for a particular VM, so users might accidentally them down (or pause, etc.).
Especially
i think it's bad if the VM is placed under a HA policy that has 'stopped' as
target, as
that will try to stop the VM by itself. (Though this might be a configuration
error in itself?)
A quick way to fix this would be to have a (custom) lock in our VMs. For
longer running tasks
that block a guest, we have a line 'lock: XXXX' in the config that prevents
our stack
from doing most operations.
Putting that in would be a very short call to our perl code that locks the
config locally
( `PVE::QemuConfig->lock_config($vmid, $updatefn) ), checks for existing
locks,
updates the config with a new (custom) lock and writes it again.
Though i must admit, I'm not sure if custom locks outside of our defined ones
would work,
but I'm sure we could add a 'custom' lock that you could use, should my
mentioned
approach not work properly.
* Also, I noticed that when a guest is started from your stack, you modify the
QEMU command line a
bit, namely removing some options that would be necessary to start the VM
during the backup.
Is there a specific reason why you do it this way, instead of starting the VM
through
our API/CLI?
A more general question last: What is the process for our/your users and us if
they/we
find a bug? Where can they be reported to you?
I hope this helps
Best regards
Dominik
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
