On Mon, 12 Jun 2017 09:04:38 +0200
Fabian Grünbichler wrote:
>
> but the LXC resize code does not set the running flag when resizing a
> volume, it always passes 0.
>
Strange, it seems to work here? I will investigate further. Maybe use
the same trick I use elsewhere:
my $run = PVE::QemuServer:
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 ther
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 s
On Thu, Jun 08, 2017 at 08:35:31PM +0200, Michael Rasmussen wrote:
> On Thu, 8 Jun 2017 19:38:23 +0200
> Michael Rasmussen wrote:
>
> > On Thu, 8 Jun 2017 19:21:50 +0200
> > Michael Rasmussen wrote:
> >
> > > I seem to have found a bug in the API because changing the size through
> > > the API
On Thu, 8 Jun 2017 19:38:23 +0200
Michael Rasmussen wrote:
> On Thu, 8 Jun 2017 19:21:50 +0200
> Michael Rasmussen 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 si
On Thu, 8 Jun 2017 19:21:50 +0200
Michael Rasmussen 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 GU
On Thu, 8 Jun 2017 18:15:13 +0200
Michael Rasmussen wrote:
> On Thu, 8 Jun 2017 18:07:26 +0200
> Michael Rasmussen wrote:
>
> > Both host and storage. FreeNAS requires a removal of the
> > 'targettoexent' and a new reassigning of targettoextent between
> > target and extent. This reassignment b
On Thu, 8 Jun 2017 17:06:30 +0200 (CEST)
Alexandre DERUMIER wrote:
>
> But I remember to use qmp command to tell the vm the new size of disk (even
> if it was already resized on the host)
>
Is there an equivalent to qmp block_resize for LXC?
--
Hilsen/Regards
Michael Rasmussen
Get my public
On Thu, 8 Jun 2017 18:07:26 +0200
Michael Rasmussen wrote:
> Both host and storage. FreeNAS requires a removal of the
> 'targettoexent' and a new reassigning of targettoextent between
> target and extent. This reassignment brakes the connection sort of like
I stand corrected ;-)
Initial assigmen
On Thu, 8 Jun 2017 17:06:30 +0200 (CEST)
Alexandre DERUMIER wrote:
>
> do you talk have about lun size on the host ? On the host, a simple iscsi
> rescan should be able to detect new size.
>
Both host and storage. FreeNAS requires a removal of the
'targettoexent' and a new reassigning of targe
-devel"
Envoyé: Jeudi 8 Juin 2017 16:35:26
Objet: Re: [pve-devel] FreeNAS plugin: Status
On Thu, 8 Jun 2017 16:00:50 +0200 (CEST)
Alexandre DERUMIER wrote:
>
> it should work if you send qmp block_resize command to vm,
> after resize the lun on the host.
>
It is not the VM
On Thu, 8 Jun 2017 16:00:50 +0200 (CEST)
Alexandre DERUMIER wrote:
>
> it should work if you send qmp block_resize command to vm,
> after resize the lun on the host.
>
It is not the VM as such but more related to the scsi subsystem. The
disk geometry is fixed at the time the LUN is attached to
he lun on the host.
- Mail original -
De: "datanom.net"
À: "pve-devel"
Envoyé: Jeudi 8 Juin 2017 11:58:59
Objet: Re: [pve-devel] FreeNAS plugin: Status
On 2017-06-08 09:31, Fabian Grünbichler wrote:
>
> no, IMHO this should work. I think the problem is (this time al
On 2017-06-08 09:31, Fabian Grünbichler wrote:
no, IMHO this should work. I think the problem is (this time almost
certainly ;)) the colon. the path is just quoted using
PVE::Tools::shellquote, which is a wrapper around
String::ShellQuote::shell_quote. Similarly, PVE::Tools::run_command
will
u
On Wed, Jun 07, 2017 at 06:57:42PM +0200, Michael Rasmussen wrote:
> Hi all,
>
> Status for this plugin is in such a way that I hopefully should be able
> to release a beta later this week;-)
>
> VM CT
> create YES YES
> delete YES
On Wed, 7 Jun 2017 18:57:42 +0200
Michael Rasmussen wrote:
> When CT is online:
> 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
> /d
On Wed, 7 Jun 2017 19:50:17 +0200
Michael Rasmussen wrote:
> BTW. Should the disks containing the state of live snapshots be part of
> the list displayed when entering storage content? See snapshot
>
Snapshot: https://snag.gy/U3IysH.jpg
--
Hilsen/Regards
Michael Rasmussen
Get my public GnuPG
BTW. Should the disks containing the state of live snapshots be part of
the list displayed when entering storage content? See snapshot
--
Hilsen/Regards
Michael Rasmussen
Get my public GnuPG keys:
michael rasmussen cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir datanom n
Hi all,
Status for this plugin is in such a way that I hopefully should be able
to release a beta later this week;-)
VM CT
create YES YES
delete YES YES
resize YES Note 1 (Needs fixing)
snapshot
offline
19 matches
Mail list logo
