[pve-devel] [PATCH v3 qemu-server 10/11] blockdev: add backing_chain support

Fabian Grünbichler f.gruenbichler at proxmox.com
Thu Jan 9 12:57:40 CET 2025


> Alexandre Derumier via pve-devel <pve-devel at lists.proxmox.com> hat am 16.12.2024 10:12 CET geschrieben:
> We need to define name-nodes for all backing chain images,
> to be able to live rename them with blockdev-reopen
> 
> For linked clone, we don't need to definebase image(s) chain.
> They are auto added with #block nodename.
> 
> Signed-off-by: Alexandre Derumier <alexandre.derumier at groupe-cyllene.com>
> ---
>  PVE/QemuServer.pm | 34 ++++++++++++++++++++++++++++++++++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
> index dc12b38f..3a3feadf 100644
> --- a/PVE/QemuServer.pm
> +++ b/PVE/QemuServer.pm
> @@ -1618,6 +1618,38 @@ sub generate_throttle_group {
>     return $throttle_group;
>  }
>  
> +sub generate_backing_blockdev {
> +    my ($storecfg, $snapshots, $deviceid, $drive, $id) = @_;
> +
> +    my $snapshot = $snapshots->{$id};
> +    my $order = $snapshot->{order};
> +    my $parentid = $snapshot->{parent};
> +    my $snap_fmt_nodename = "fmt-$deviceid-$order";
> +    my $snap_file_nodename = "file-$deviceid-$order";

would it make sense to use the snapshot name here instead of the order? that would allow a deterministic mapping even when snapshots are removed..

> +
> +    my $snap_file_blockdev = generate_file_blockdev($storecfg, $drive, $snap_file_nodename);
> +    $snap_file_blockdev->{filename} = $snapshot->{file};
> +    my $snap_fmt_blockdev = generate_format_blockdev($storecfg, $drive, $snap_fmt_nodename, $snap_file_blockdev, 1);
> +    $snap_fmt_blockdev->{backing} = generate_backing_blockdev($storecfg, $snapshots, $deviceid, $drive, $parentid) if $parentid;
> +    return $snap_fmt_blockdev;
> +}
> +
> +sub generate_backing_chain_blockdev {
> +    my ($storecfg, $deviceid, $drive) = @_;
> +
> +    my $volid = $drive->{file};
> +    my $do_snapshots_with_qemu = do_snapshots_with_qemu($storecfg, $volid, $deviceid);
> +    return if !$do_snapshots_with_qemu || $do_snapshots_with_qemu != 2;
> +
> +    my $chain_blockdev = undef;
> +    PVE::Storage::activate_volumes($storecfg, [$volid]);
> +    #should we use qemu config to list snapshots ?

from a data consistency PoV, trusting the qcow2 metadata is probably safer.. but we could check that the storage and the config agree, and error out otherwise?

> +    my $snapshots = PVE::Storage::volume_snapshot_info($storecfg, $volid);
> +    my $parentid = $snapshots->{'current'}->{parent};
> +    $chain_blockdev = generate_backing_blockdev($storecfg, $snapshots, $deviceid, $drive, $parentid) if $parentid;
> +    return $chain_blockdev;
> +}
> +
>  sub generate_file_blockdev {
>      my ($storecfg, $drive, $nodename) = @_;
>  
> @@ -1816,6 +1848,8 @@ sub generate_drive_blockdev {
>      my $blockdev_file = generate_file_blockdev($storecfg, $drive, $file_nodename);
>      my $fmt_nodename = "fmt-drive-$drive_id";
>      my $blockdev_format = generate_format_blockdev($storecfg, $drive, $fmt_nodename, $blockdev_file, $force_readonly);
> +    my $backing_chain  = generate_backing_chain_blockdev($storecfg, "drive-$drive_id", $drive);
> +    $blockdev_format->{backing} = $backing_chain if $backing_chain;
>  
>      my $blockdev_live_restore = undef;
>      if ($live_restore_name) {
> -- 
> 2.39.5




More information about the pve-devel mailing list