Re: [pve-devel] [PATCH qemu-server 1/1] create_vm: assume HA state 'started' when live-restoring guests

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

Am 21.11.25 um 11:32 schrieb Fiona Ebner:
> Am 21.11.25 um 11:23 AM schrieb Thomas Lamprecht:
>> Am 21.11.25 um 11:15 schrieb Fiona Ebner:
>>> Am 21.11.25 um 11:04 AM schrieb Thomas Lamprecht:
>>>> We lock the config on restore, or?
>>>> If so, couldn't we handle this in the HA stack and do not shutdown if a
>>>> restore lock is present in the config?
>>>
>>> But that'd be more coupling? Further below in the endpoint we have (two
>>> instances of):
>>
>> Making the HA actually aware of how the resources it manages work, so that
>> it can make better decisions, is definitively not more coupling.
> 
> Fair point.

To also be fair, it is coupling, but this is warranted one (at least for the
current design); not all coupling is inherently bad, it always should be
rather explicit and not hidden though.

>>>>             if ($ha_managed) {
>>>>                 print "Add as HA resource\n";
>>>>                 my $state = $start_after_create ? 'started' : 'stopped';
>>>>                 my $cmd = ['ha-manager', 'add', "vm:$vmid", '--state', $state];
>>>>                 eval { PVE::Tools::run_command($cmd); };
>>>>                 warn $@ if $@;
>>>>             }
>>>
>>> So we could just put $start_after_create || $live_restore there
>>
>> Does not solves the case for when restores over a existing VM that is a HA
>> resource already, FWICT.
> 
> The code block above still needs fixing regardless? Since it sets the
> state for a newly added resource.

Yes, I think so. One is for not stopping during restore and the other is
for not stopping them after the restore, and live-restore already *does*
imply start-after-create (well, restore here, but same same).


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel