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.gruenbich...@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..
_______________________________________________
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
