all lists on lists.proxmox.com
 help / color / mirror / Atom feed
* [pve-devel] [PATCH qemu-server 1/1] Do not start VM twice when rollbacking with --start
@ 2022-11-21 12:29 Stefan Hanreich
  2022-11-21 12:44 ` Fabian Grünbichler
  0 siblings, 1 reply; 3+ messages in thread
From: Stefan Hanreich @ 2022-11-21 12:29 UTC (permalink / raw)
  To: pve-devel

When rollbacking to the snapshot of a VM that includes RAM, the VM
gets started by the rollback task anyway, so no additional start task is
needed. Previously, when running rollback with the --start parameter
and the VM snapshot includes RAM, a start task was created. That task
failed because the VM had already been started by the rollback task.

Additionally documented this behaviour in the description of the --start
parameter

Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
---
 PVE/API2/Qemu.pm | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index 6bdcce2..7263a1a 100644
--- a/PVE/API2/Qemu.pm
+++ b/PVE/API2/Qemu.pm
@@ -5064,7 +5064,8 @@ __PACKAGE__->register_method({
 	    snapname => get_standard_option('pve-snapshot-name'),
 	    start => {
 		type => 'boolean',
-		description => "Whether the VM should get started after rolling back successfully",
+		description => "Whether the VM should get started after rolling back successfully."
+		    . " A VM will always be started when rollbacking a snapshot with RAM included, regardless of this parameter.",
 		optional => 1,
 		default => 0,
 	    },
@@ -5092,7 +5093,13 @@ __PACKAGE__->register_method({
 	    PVE::QemuConfig->snapshot_rollback($vmid, $snapname);
 
 	    if ($param->{start}) {
-		PVE::API2::Qemu->vm_start({ vmid => $vmid, node => $node });
+		my $conf = PVE::QemuConfig->load_config($vmid);
+		my $snap = $conf->{snapshots}->{$snapname};
+		die "snapshot '$snapname' does not exist\n" if !defined($snap);
+
+		if (!$snap->{vmstate}) {
+		    PVE::API2::Qemu->vm_start({ vmid => $vmid, node => $node });
+		}
 	    }
 	};
 
-- 
2.30.2




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [pve-devel] [PATCH qemu-server 1/1] Do not start VM twice when rollbacking with --start
  2022-11-21 12:29 [pve-devel] [PATCH qemu-server 1/1] Do not start VM twice when rollbacking with --start Stefan Hanreich
@ 2022-11-21 12:44 ` Fabian Grünbichler
  2022-11-21 12:57   ` Stefan Hanreich
  0 siblings, 1 reply; 3+ messages in thread
From: Fabian Grünbichler @ 2022-11-21 12:44 UTC (permalink / raw)
  To: Proxmox VE development discussion

On November 21, 2022 1:29 pm, Stefan Hanreich wrote:
> When rollbacking to the snapshot of a VM that includes RAM, the VM
> gets started by the rollback task anyway, so no additional start task is
> needed. Previously, when running rollback with the --start parameter
> and the VM snapshot includes RAM, a start task was created. That task
> failed because the VM had already been started by the rollback task.
> 
> Additionally documented this behaviour in the description of the --start
> parameter
> 
> Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
> ---
>  PVE/API2/Qemu.pm | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
> index 6bdcce2..7263a1a 100644
> --- a/PVE/API2/Qemu.pm
> +++ b/PVE/API2/Qemu.pm
> @@ -5064,7 +5064,8 @@ __PACKAGE__->register_method({
>  	    snapname => get_standard_option('pve-snapshot-name'),
>  	    start => {
>  		type => 'boolean',
> -		description => "Whether the VM should get started after rolling back successfully",
> +		description => "Whether the VM should get started after rolling back successfully."
> +		    . " A VM will always be started when rollbacking a snapshot with RAM included, regardless of this parameter.",
>  		optional => 1,
>  		default => 0,
>  	    },
> @@ -5092,7 +5093,13 @@ __PACKAGE__->register_method({
>  	    PVE::QemuConfig->snapshot_rollback($vmid, $snapname);
>  
>  	    if ($param->{start}) {
> -		PVE::API2::Qemu->vm_start({ vmid => $vmid, node => $node });
> +		my $conf = PVE::QemuConfig->load_config($vmid);
> +		my $snap = $conf->{snapshots}->{$snapname};
> +		die "snapshot '$snapname' does not exist\n" if !defined($snap);
> +
> +		if (!$snap->{vmstate}) {
> +		    PVE::API2::Qemu->vm_start({ vmid => $vmid, node => $node });
> +		}

this could also just call check_running, and skip the start call if it returns
true.

if ($param_start && !check_running(..)) {
    ..
}

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




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [pve-devel] [PATCH qemu-server 1/1] Do not start VM twice when rollbacking with --start
  2022-11-21 12:44 ` Fabian Grünbichler
@ 2022-11-21 12:57   ` Stefan Hanreich
  0 siblings, 0 replies; 3+ messages in thread
From: Stefan Hanreich @ 2022-11-21 12:57 UTC (permalink / raw)
  To: Proxmox VE development discussion, Fabian Grünbichler


On 11/21/22 13:44, Fabian Grünbichler wrote:
> On November 21, 2022 1:29 pm, Stefan Hanreich wrote:
>> When rollbacking to the snapshot of a VM that includes RAM, the VM
>> gets started by the rollback task anyway, so no additional start task is
>> needed. Previously, when running rollback with the --start parameter
>> and the VM snapshot includes RAM, a start task was created. That task
>> failed because the VM had already been started by the rollback task.
>>
>> Additionally documented this behaviour in the description of the --start
>> parameter
>>
>> Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
>> ---
>>   PVE/API2/Qemu.pm | 11 +++++++++--
>>   1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
>> index 6bdcce2..7263a1a 100644
>> --- a/PVE/API2/Qemu.pm
>> +++ b/PVE/API2/Qemu.pm
>> @@ -5064,7 +5064,8 @@ __PACKAGE__->register_method({
>>   	    snapname => get_standard_option('pve-snapshot-name'),
>>   	    start => {
>>   		type => 'boolean',
>> -		description => "Whether the VM should get started after rolling back successfully",
>> +		description => "Whether the VM should get started after rolling back successfully."
>> +		    . " A VM will always be started when rollbacking a snapshot with RAM included, regardless of this parameter.",
>>   		optional => 1,
>>   		default => 0,
>>   	    },
>> @@ -5092,7 +5093,13 @@ __PACKAGE__->register_method({
>>   	    PVE::QemuConfig->snapshot_rollback($vmid, $snapname);
>>   
>>   	    if ($param->{start}) {
>> -		PVE::API2::Qemu->vm_start({ vmid => $vmid, node => $node });
>> +		my $conf = PVE::QemuConfig->load_config($vmid);
>> +		my $snap = $conf->{snapshots}->{$snapname};
>> +		die "snapshot '$snapname' does not exist\n" if !defined($snap);
>> +
>> +		if (!$snap->{vmstate}) {
>> +		    PVE::API2::Qemu->vm_start({ vmid => $vmid, node => $node });
>> +		}
> this could also just call check_running, and skip the start call if it returns
> true.
>
> if ($param_start && !check_running(..)) {
>      ..
> }
sounds way better, will implement it this way - ty
>
>>   	    }
>>   	};
>>   
>> -- 
>> 2.30.2
>>
>>
>> _______________________________________________
>> pve-devel mailing list
>> pve-devel@lists.proxmox.com
>> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>>
>>
>>
>
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
>




^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-11-21 12:57 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-21 12:29 [pve-devel] [PATCH qemu-server 1/1] Do not start VM twice when rollbacking with --start Stefan Hanreich
2022-11-21 12:44 ` Fabian Grünbichler
2022-11-21 12:57   ` Stefan Hanreich

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal