On Fri, Jun 09, 2017 at 03:47:51PM +0200, datanom.net wrote:
> On 2017-06-09 10:03, Fabian Grünbichler wrote:
> >
> > only allowing offline resizing is not possible on a storage plugin level
> > for raw volumes and containers - see PVE::API2::LXC.pm resize_vm API end
> > point and the comment there. you either need to wait for the FreeNAS bug
> > fix or special case your storage type in the container code (you can
> > probably guess which variant we prefer ;))
> >
> I agree. But my best guess is that this will not be fixed in current
> old-stable (9.10.x) since current stable (10.x) has been discontinued and
> all efforts are directed at releasing the next stable (11.x) as soon as
> possible. 11.x also brings enhancements and new features to the API.
>
> Giving users the choice of resizing disks though only offline is better than
> no choice at all?
>
> > PVE::Storage::volume_resize's running parameter is used to return early
> > if Qemu is supposed to do the actual resizing (this is not documented
> > very well, I know) as opposed to just rescanning for the new size.
> >
> > as an example, the base plugin (PVE::Storage::Plugin) has the following
> > in its volume_resize method:
> >
> Adding a check to the storage plugins volume_resize method whether running
> is true or not seems to be sufficient. Eg
> die "some info" if $running. So there does not need to be any changes in
> QemuServer or LXC code at all.
but the LXC resize code does not set the running flag when resizing a
volume, it always passes 0.
>
> PS. I have just found out that full clones are done outside of the storage
> plugins which is ok. For the FreeNAS plugin it is a problem though since the
> clone_disk method in QemuServer calls activate_volumes before cloning - this
> is as it should, but it does not call deactivate_volumes when finished which
> leaves attached LUN's on the host.
>
> Should I create some kind of timer based functions which performs clean-up
> of attached LUN's for offline VM/CT?
> eg.
> For all exposed LUN's
> my ($vmid, $volname) = get_vmid($lun);
> my $run = PVE::QemuServer::check_running($vmid);
> if (!$run) {
> $run = PVE::LXC::check_running($vmid);
> }
> $class->deactivate_volume($storeid, $scfg, $volname) unless $run;
>
but a guest running is not the only (potential) long running action
which needs the disk activated. I don't think this would work (safely)..
_______________________________________________
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
