public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Fiona Ebner <f.ebner@proxmox.com>
To: "Proxmox VE development discussion" <pve-devel@lists.proxmox.com>,
	"Fabian Grünbichler" <f.gruenbichler@proxmox.com>
Subject: Re: [pve-devel] [PATCH qemu-server 1/1] snapshot: prohibit snapshot with ram if vm has a passthrough pci device
Date: Tue, 14 May 2024 15:03:51 +0200	[thread overview]
Message-ID: <e589a7ee-63ec-417e-a1c4-25ef33b099a7@proxmox.com> (raw)
In-Reply-To: <1712914044.dmqqhkfhvy.astroid@yuna.none>

Am 12.04.24 um 11:32 schrieb Fabian Grünbichler:
> On March 19, 2024 4:08 pm, Hannes Duerr wrote:
>> When a snapshot is created with RAM, qemu attempts to save not only the
>> RAM content, but also the internal state of the PCI devices.
>>
>> However, as not all drivers support this, this can lead to the device
>> drivers in the VM not being able to handle the saved state during the
>> restore/rollback and in conclusion the VM might crash. For this reason,
>> we now generally prohibit snapshots with RAM for VMs with passthrough
>> devices.
>>
>> In the future, this prohibition can of course be relaxed for individual
>> drivers that we know support it, such as the vfio driver
>>

We're already using pci-vfio, see [0]. So not sure how that relaxation
would look like. Probably it'd need to be a flag for the hostpci
property similar to what's done in Dominik's "implement experimental
vgpu live migration​" series for mapped devices.

That said, looking into this and wondering why QEMU doesn't check it,
there's an issue in that our savevm-async code does not properly check
for all migration blockers (only some of them)! I'll work out a patch
for that. If we can be sure not to break any existing users with the
below code, we can still apply it too of course.

>> Signed-off-by: Hannes Duerr <h.duerr@proxmox.com>
>> ---
>>  PVE/API2/Qemu.pm | 10 ++++++++++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
>> index 40b6c30..0acd1c7 100644
>> --- a/PVE/API2/Qemu.pm
>> +++ b/PVE/API2/Qemu.pm
>> @@ -5101,6 +5101,16 @@ __PACKAGE__->register_method({
>>  	die "unable to use snapshot name 'pending' (reserved name)\n"
>>  	    if lc($snapname) eq 'pending';
>>  
>> +	if ($param->{vmstate}) {
>> +	    my $conf = PVE::QemuConfig->load_config($vmid);
>> +
>> +	    for my $key (keys %$conf) {
>> +		next if $key !~ /^hostpci\d+/;
>> +		die "cannot snapshot VM with RAM due to passed-through PCI device(s), which lack"
>> +		    ." the possibility to save/restore their internal state\n";
>> +	    }
>> +	}
> 
> isn't the same also true of other local resources (e.g., passed-through
> USB?)?
> 
> maybe we could find a way to unify the checks we do for live migration
> (PVE::QemuServer::check_local_resources), since that is almost the same
> code inside Qemu as a stateful snapshot+rollback?
> 
> (not opposed to applying this before that happens though, just a
> question in general..)
> 

Similarly, there is the suspend API endpoint that could benefit from
having a single helper. I assume this code was copied from there.

[0]:
https://git.proxmox.com/?p=qemu-server.git;a=blob;f=PVE/QemuServer/PCI.pm;h=1673041bbe7a5d638a0ee9c56ea6bbb31027023b;hb=HEAD#l625


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

  reply	other threads:[~2024-05-14 13:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-19 15:08 Hannes Duerr
2024-04-12  9:32 ` Fabian Grünbichler
2024-05-14 13:03   ` Fiona Ebner [this message]
2024-05-14 14:08     ` Fiona Ebner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e589a7ee-63ec-417e-a1c4-25ef33b099a7@proxmox.com \
    --to=f.ebner@proxmox.com \
    --cc=f.gruenbichler@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal