Am 13.11.24 um 11:52 schrieb Fabian Grünbichler:
> didn't give this too close a look since it's an example only, but the
> hard-coded NBD indices make me wonder whether we want to have some sort
> of mechanism to "reserve" NBD slots while using them, at least for *our*
> usage?
Fixed in v5. I just copied over the corresponding method added in v4 in
qemu-server. This plugin is just a POC to test all mechanisms. I'll add
a note there to explain that actual plugins should never need to mess
with NBD block nodes, i.e. either they should speak NBD with the export
directly instead of binding to a block device node, or use the
'block-device' backup mechanism.
> On November 7, 2024 5:51 pm, Fiona Ebner wrote:
>> +my sub get_bitmap_id {
>> + my ($self, $vmid, $vmtype) = @_;
>> +
>> + return if $self->{'storage-plugin'}->get_vm_backup_mode($self->{scfg})
>> ne 'incremental';
>> +
>> + my $previous_info_dir = "$self->{scfg}->{path}/$vmid/";
>> +
>> + my $previous_info_file = "$previous_info_dir/previous-info";
>> + my $info = file_read_firstline($previous_info_file) // '';
>> + $self->{$vmid}->{'old-previous-info'} = $info;
>> + my ($bitmap_id, $previous_backup_id) = $info =~ m/^(\d+)\s+(\d+)$/;
>> + my $previous_backup_dir =
>> + $previous_backup_id ?
>> "$self->{scfg}->{path}/$vmid/$vmtype-$previous_backup_id" : undef;
>
> so the backup ID is an epoch - wouldn't it be nicer to use the formatted
> one as subdir, rather than the epoch itself?
If we ever want to spin out a variant of a directory plugin for real
production support, yes sure. I didn't bother for the example here.
>> +
>> + if ($bitmap_id && -d $previous_backup_dir) {
>> + $self->{$vmid}->{'previous-backup-dir'} = $previous_backup_dir;
>> + } else {
>> + # need to start fresh if there is no previous ID or the associated
>> backup doesn't exist
>> + $bitmap_id = $self->{$vmid}->{'backup-time'};
>> + }
>> +
>> + $self->{$vmid}->{'bitmap-id'} = $bitmap_id;
>> + make_path($previous_info_dir);
>> + die "unable to create directory $previous_info_dir\n" if !-d
>> $previous_info_dir;
>> + file_set_contents($previous_info_file, "$bitmap_id
>> $self->{$vmid}->{'backup-time'}");
>> +
>> + return $bitmap_id;
>> +}
>> +
>> +# Backup Provider API
>> +
>> +sub new {
>> + my ($class, $storage_plugin, $scfg, $storeid, $log_function) = @_;
>> +
>> + my $self = bless {
>> + scfg => $scfg,
>> + storeid => $storeid,
>> + 'storage-plugin' => $storage_plugin,
>> + 'log-function' => $log_function,
>> + }, $class;
>> +
>> + return $self;
>> +}
>> +
>> +sub provider_name {
>> + my ($self) = @_;
>> +
>> + return 'dir provider example';
>> +}
>> +
>> +# Hooks
>> +
>> +my sub job_start {
>> + my ($self, $start_time) = @_;
>> +
>> + log_info($self, "job start hook called");
>> +
>> + run_command(["modprobe", "nbd"]);
>
> this duplicates the modprobe in qemu-server, but without the parameter..
Since v4, qemu-server ships a modprobe config to load it during boot.
Replaced the above with a die if not already loaded. Thinking about
this, if we do go for that config, I'll also add a postinst hook to load
it during upgrade of qemu-server in v5.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
