On Thu, Jun 08, 2017 at 08:35:31PM +0200, Michael Rasmussen wrote:
> On Thu, 8 Jun 2017 19:38:23 +0200
> Michael Rasmussen <m...@datanom.net> wrote:
>
> > On Thu, 8 Jun 2017 19:21:50 +0200
> > Michael Rasmussen <m...@datanom.net> wrote:
> >
> > > I seem to have found a bug in the API because changing the size through
> > > the API all though the zvol is properly resized rescanning the session
> > > on the client side does not show the changed size. If I do the same
> > > from the FreeNAS GUI then it works as expected!
> > >
> > Created a bug report: https://bugs.freenas.org/issues/24432
> >
> To conclude on this long thread:
> 1) Online resize is not functional due to the bug in FreeNAS API so
> until this bug is resolved only allow offline resize
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 ;))
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:
----8<----
die "can't resize this image format\n" if $volname !~ m/\.(raw|qcow2)$/;
return 1 if $running;
my $path = $class->filesystem_path($scfg, $volname);
my $format = ($class->parse_volname($volname))[6];
my $cmd = ['/usr/bin/qemu-img', 'resize', '-f', $format, $path , $size];
run_command($cmd, timeout => 10);
return undef;
---->8----
because modifying a qcow2 file while it is in use by a Qemu process
leads to corruption, and Qemu can just resize it itself with the
block_resize command. but when using a raw file with a container, we
need to resize the raw file with qemu-img, so we always set $running to
0 (so $running should actually be called something like
$qemu_and_running ;)). the SheepDog and Ceph plugins have similar
mechanisms, because we use their respective APIs in Qemu to access the
image contents, and can use those same APIs to resize them as well.
> 2) If I manually resizes the disk in the FreeNAS gui and rescan the
> iscsi session on the client online resize works with both VM and CT
> VM:
> 1) Change size of zvol
> 2) rescan iscsi session
> 3) qmp block_resize drive-scsiX +size[KMG]
> CT:
> 1) Change size of zvol
> 2) rescan iscsi session
> 3) unshare -m -- sh -c 'mount --make-rprivate / && mount
> /dev/disk/by-path/ip-10.0.1.32:3260-iscsi-iqn.2005-10.org.freenas.ctl:some_lun
> /tmp && resize2fs
> /dev/disk/by-path/ip-10.0.1.32:3260-iscsi-iqn.2005-10.org.freenas.ctl:some_lun'
>
>
> --
> Hilsen/Regards
> Michael Rasmussen
>
> Get my public GnuPG keys:
> michael <at> rasmussen <dot> cc
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
> mir <at> datanom <dot> net
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
> mir <at> miras <dot> org
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
> --------------------------------------------------------------
> /usr/games/fortune -es says:
> If redness or swelling develop, consult physician promptly.
> _______________________________________________
> pve-devel mailing list
> pve-devel@pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
_______________________________________________
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
