> It whats an 'smart' idea I hand but after using the plugin for several months
> and
> testing on a lot of different distributions I am beginning to wonder whether
> this
> should be dropped. I have not been able to find any reel usage for it.
Yes, please can we remove all unneeded things (can
Note that nexenta don't have sudo command installed by default.
(I think also that we can drop it)
I also notice 2 properties : chap and pwd , which are not used.
do you plan to use them later ?
- Mail original -
De: "Michael Rasmussen"
À: pve-devel@pve.proxmox.com
Envoyé: Merc
On Wed, 2 Oct 2013 04:44:43 +
Dietmar Maurer wrote:
>
> I still don't understand that 'sudo' flag - I thought we always connect as
> 'root' anyways?
>
It whats an 'smart' idea I hand but after using the plugin for several
months and testing on a lot of different distributions I am beginnin
applied (+ minor cleanups).
Many thanks for that great code!
> -Original Message-
> From: pve-devel-boun...@pve.proxmox.com [mailto:pve-devel-
> boun...@pve.proxmox.com] On Behalf Of Alexandre Derumier
> Sent: Mittwoch, 02. Oktober 2013 04:58
> To: pve-devel@pve.proxmox.com
> Subject: [pv
> zfs:omnios
> blocksize 8k
> target iqn.2010-09.org.openindiana:target1
> pool pool1
> iscsiprovider comstar
> portal 192.168.0.1
> sudo 1 (optionnal)
I still don't understand that 'sudo' flag - I thought we always connect as
'root' anyways?
> Forgot to ask when this kernel update is scheduled?
> Seems like a major improvement.
It is already on pve-no-subscription. I wanted to move it to enterprise next
week, but it looks
quite stable so maybe we should move it this week.
___
pve-devel mai
It's working fine, don't have see any regression.
Thanks !
- Mail original -
De: "Alexandre DERUMIER"
À: "Dietmar Maurer"
Cc: pve-devel@pve.proxmox.com
Envoyé: Mardi 1 Octobre 2013 17:48:13
Objet: Re: [pve-devel] qemu-server : check_volume_access : find $path is undef
Thanks,I'
From: Michael Rasmussen
example of storage.cfg
zfs:omnios
blocksize 8k
target iqn.2010-09.org.openindiana:target1
pool pool1
iscsiprovider comstar
portal 192.168.0.1
sudo 1 (optionnal)
content images
note for fast ssh login:
on solari
This is the zfs storage plugin from Michael + my cleanup
Tested on omnios and nexenta (community and enterprise).
(I'm think about to drop the nexenta plugin, as it's working 100% with this
plugin,
and it's a lot faster than nexenta api + solve the missing zfs rename command
from nexenta api)
On Tue, 1 Oct 2013 21:09:29 +0200
Michael Rasmussen wrote:
> Hi Dietmar,
>
> On Tue, 1 Oct 2013 19:18:59 +0200
> Michael Rasmussen wrote:
>
> > On Tue, 01 Oct 2013 10:46:20 +0200
> > Michael Rasmussen wrote:
> >
> > > I will test at home this evening.
> > >
> I can also confirm that backing
Hi Dietmar,
On Tue, 1 Oct 2013 19:18:59 +0200
Michael Rasmussen wrote:
> On Tue, 01 Oct 2013 10:46:20 +0200
> Michael Rasmussen wrote:
>
> > I will test at home this evening.
> >
I can also confirm that backing up a CT to a NFS share on my Qnap
(Linux kernel) now works again.
To a Solaris NF
On Tue, 01 Oct 2013 10:46:20 +0200
Michael Rasmussen wrote:
> I will test at home this evening.
>
I have now done the test.
When is fails the following is displayed:
mnt/pve/qnap_nfs/testdir/src/file1 /mnt/pve/qnap_nfs/testdir/dst/file1
differ: byte 1, line 1
Linux nfs sha
Thanks,I'll try tomorrow
- Mail original -
De: "Dietmar Maurer"
À: "Alexandre Derumier" , pve-devel@pve.proxmox.com
Envoyé: Mardi 1 Octobre 2013 12:44:15
Objet: RE: [pve-devel] qemu-server : check_volume_access : find $path is undef
I use PVE::Storage::abs_filesystem_path() inst
I also use new use new PVE::Storage::abs_filesystem_path() in order to
correctly activate the storage.
Please test.
> -Original Message-
> From: pve-devel-boun...@pve.proxmox.com [mailto:pve-devel-
> boun...@pve.proxmox.com] On Behalf Of Alexandre Derumier
> Sent: Mittwoch, 25. September
I use PVE::Storage::abs_filesystem_path() instead.
Please can you test if it works for you?
> -Original Message-
> From: pve-devel-boun...@pve.proxmox.com [mailto:pve-devel-
> boun...@pve.proxmox.com] On Behalf Of Alexandre Derumier
> Sent: Mittwoch, 25. September 2013 10:29
> To: pve-de
applied, but I additionally removed all path related code.
Instead, I added a new helper to PVE::Storage:
sub abs_filesystem_path {
my ($cfg, $volid) = @_;
my $path;
if (PVE::Storage::parse_volume_id ($volid, 1)) {
PVE::Storage::activate_volumes($cfg, [ $volid ]);
$pa
applied
> -Original Message-
> From: pve-devel-boun...@pve.proxmox.com [mailto:pve-devel-
> boun...@pve.proxmox.com] On Behalf Of Alexandre Derumier
> Sent: Mittwoch, 25. September 2013 10:27
> To: pve-devel@pve.proxmox.com
> Subject: [pve-devel] pve-storage : storage: add parse_volname
>
I will test at home this evening.
Dietmar Maurer wrote:
>> > However, if the destination of your tarball is on an nfs exported
>> > filesystem from a server running solaris your test case does not
>> > result in a bug. Eg the operation succeeds as expected - the
>tarball is not
>> empty.
>>
>> Y
Am 01.10.2013 10:40, schrieb Dietmar Maurer:
> applied, thank!
>
>> -Original Message-
>> From: pve-devel-boun...@pve.proxmox.com [mailto:pve-devel-
>> boun...@pve.proxmox.com] On Behalf Of Stefan Priebe
>> Sent: Montag, 30. September 2013 11:51
>> To: pve-devel@pve.proxmox.com
>> Subject:
applied, thank!
> -Original Message-
> From: pve-devel-boun...@pve.proxmox.com [mailto:pve-devel-
> boun...@pve.proxmox.com] On Behalf Of Stefan Priebe
> Sent: Montag, 30. September 2013 11:51
> To: pve-devel@pve.proxmox.com
> Subject: [pve-devel] [PATCH] do not use -w switch as it breaks
> > However, if the destination of your tarball is on an nfs exported
> > filesystem from a server running solaris your test case does not
> > result in a bug. Eg the operation succeeds as expected - the tarball is not
> empty.
>
> You tested both test cases?
Anyway, it does not matter, because t
> However, if the destination of your tarball is on an nfs exported filesystem
> from
> a server running solaris your test case does not result in a bug. Eg the
> operation
> succeeds as expected - the tarball is not empty.
You tested both test cases?
On 10-01-2013 09:49, Dietmar Maurer wrote:
What I ment to say was that this bug only shows up when nfs share is
mounted
on a server running linux. If the server runs with a solaris kernel
you cannot
replicate the bug.
Yes, because Solaris does not have any OpenVZ patches. OpenVZ only
runs on
> > Sigh, it is related to OpenVZ NFS quota code. Will report a bug.
>
> Seems there is already a fix:
>
> https://bugzilla.openvz.org/show_bug.cgi?id=2738
>
> Will try compile and upload a new kernel including that fix.
I just uploaded a new kernel including a fix for this bug to the
pve-no-s
> What I ment to say was that this bug only shows up when nfs share is mounted
> on a server running linux. If the server runs with a solaris kernel you cannot
> replicate the bug.
Yes, because Solaris does not have any OpenVZ patches. OpenVZ only runs on
Linux.
__
What I ment to say was that this bug only shows up when nfs share is mounted on
a server running linux. If the server runs with a solaris kernel you cannot
replicate the bug.
Dietmar Maurer wrote:
>> > Sigh, it is related to OpenVZ NFS quota code. Will report a bug.
>> >
>> >
>> But it is not g
> Not sure what you talk about - yes, it is related to a bug inside the openvz
> kernel, in the NFS quota code.
Note: This NFS (local) quota code is 100% OpenVZ, but causes bug for normal NFS
mounts ouside of containers.
___
pve-devel mailing list
pve-
> > Sigh, it is related to OpenVZ NFS quota code. Will report a bug.
> >
> >
> But it is not generally related to NFS I am more reluctant to think that the
> situation relates to a combination of OpenVZ and a NFS
Not sure what you talk about - yes, it is related to a bug inside the openvz
kernel
On 10-01-2013 08:19, Dietmar Maurer wrote:
seems fstat return a block count of zero for NFS files, and tar detect
sparse files
with:
if (ST_NBLOCKS (st->stat) == 0) {
so that always matches!
need to dig deeper now.
Sigh, it is related to OpenVZ NFS quota code. Will report a bug.
But it is
> > seems fstat return a block count of zero for NFS files, and tar detect
> > sparse
> files
> > with:
> >
> > if (ST_NBLOCKS (st->stat) == 0) {
> >
> > so that always matches!
> >
> > need to dig deeper now.
>
> Sigh, it is related to OpenVZ NFS quota code. Will report a bug.
Seems there is al
30 matches
Mail list logo
