[pve-devel] [PATCH pve-storage 0/5] v5 fix regression and indentation

Fabian Grünbichler f.gruenbichler at proxmox.com
Mon Jun 19 09:33:05 CEST 2017


On Sun, Jun 18, 2017 at 12:47:30AM +0200, Michael Rasmussen wrote:
> Hi Fabian,
> 
> On Fri, 16 Jun 2017 14:21:34 +0200
> Fabian Grünbichler <f.gruenbichler at proxmox.com> wrote:
> 
> > > sub volume_resize {
> > >     my ($class, $scfg, $storeid, $volname, $size, $running) = @_;
> > > 
> > >     my ($vtype, $name, $vmid) = $class->parse_volname($volname);
> > > 
> > >     my $run = PVE::QemuServer::check_running($vmid);
> > >     if (!$run) {
> > >         $run = PVE::LXC::check_running($vmid);
> > >     }  
> > 
> > not allowed here - see comment on the very top.
> > 
> > alternative solutions:
> > - expand storage API here to split $running into two parameters, modify
> >   PVE::LXC and PVE::QemuServer to pass $running and the new parameter
> >   accordingly, adapt other plugins to handle $running && $new_parameter
> >   like they used to handle $running (if they did), adapt your plugin to
> >   die if $running to forbid online resizing for now.
> > - special case your plugin in PVE::LXC to handle running containers
> >   there (Qemu does pass $running correctly).
> > 
> I have studied this phenomenon in greater depth and more and more I
> begin to think that this is a bug burruniied deep down somewhere in
> PVE::Tools::run_command, it is not related to FreeNAS or my plugin.
> 
> When you try to resize a running container you get this error message:
> mount.nfs: Failed to resolve server /dev/disk/by-path/ip-10.0.1.32: Name or service not known
> Failed to update the container's filesystem: command '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:vm-113-lun-0 /tmp && resize2fs /dev/disk/by-path/ip-10.0.1.32:3260-iscsi-iqn.2005-10.org.freenas.ctl:vm-113-lun-0'' failed: exit code 32
> 
> If you copy/paste the command which pve-manager tries to run to the
> command line everything works as expected, it is only when runned from
> pve-manager the command fails. So resizing running CT's is disabled due
> to a bug in pve-manager and not in the FreeNAS API or the plugin.
> 
> As a side note I can tell that path now returns the path with : escaped
> as you sugggested but to no avail.

AFAICT, mount will always guess NFS if there is a ':' anywhere in the
source path:

https://anonscm.debian.org/cgit/collab-maint/pkg-util-linux.git/tree/libmount/src/context.c?h=debian/2.29.2-1#n1640

so I guess the only way to solve this is to pass "-t nonfs", which
changes the error message from

> mount.nfs: Failed to resolve server /dev/disk/by-path/ip-10.0.1.32: Name or service not known

to

> mount: special device /dev/disk/by-path/ip-10.0.1.323260-iscsi-iqn.2005-10.org.freenas.ctl:vm-113-lun-0 does not exist

because the path of course does not exist on my test system ;)

IMHO adding this is not problematic, because we never have container
volumes which are a whole NFS export, and if we had, they could not be
"raw" and resizable anyway..




More information about the pve-devel mailing list