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

[DERUMIER, Alexandre]

>  
> +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..

31 characters limit for nodename :(

if we could be able to encode the fullpath, I think it could be
easier.I don't known if qemu could be patched to allow more characters
for node names.

With a unique id by file/path (not by drive), I think it could work
with mirror/replace/...




> +
> +    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.. 
(I asked about this, because we need to active volumes for this, and
currently we are activate them after the config generation).
With this code, this activate volumes when we generate the command
line, but if user have a wrong config, we need to handle desactivate
too.

>>but we could check that the storage and the config agree, and >>error
>>out otherwise?

yes, I was thinking about this. we can list volumes from storage
without need to activate them , then check that all volumes from vm
config are present.