Hi Fabian,
>> I was following https://pve.proxmox.com/wiki/Storage:_NFS , quote: "To avoid
>> DNS lookup delays, it is usually preferable to use an
>> IP address instead of a DNS name". But yes, the DNS in our environment is
>> configured to allow reverse lookups.
>
> which - AFAIK - is still t
On Mon, May 22, 2017 at 02:52:13PM +0200, Uwe Sauter wrote:
> >>> perl -e 'use strict; use warnings; use PVE::ProcFSTools; use
> >>> Data::Dumper; print Dumper(PVE::ProcFSTools::parse_proc_mounts());'
> >>>
> >>
> >> $VAR1 = [
> >>
> >> [
> >> ':/backup/proxmox-infra',
>
Am 22.05.2017 um 15:40 schrieb Uwe Sauter:
>
>>
>> I discovered a different issue with this definition: If I go to Datacenter
>> -> node -> storage aurel -> content I only get "mount
>> error: mount.nfs: /mnt/pve/aurel is busy or already mounted (500)".
>>
>> The share is mounted again with IP ad
>
> I discovered a different issue with this definition: If I go to Datacenter ->
> node -> storage aurel -> content I only get "mount
> error: mount.nfs: /mnt/pve/aurel is busy or already mounted (500)".
>
> The share is mounted again with IP address though I didn't change the config
> after
>>
>> the culprit is likely that your storage.cfg contains the IP, but your
>> /proc/mounts contains the hostname (with a reverse lookup inbetween?).
>>
>
> I was following https://pve.proxmox.com/wiki/Storage:_NFS , quote: "To avoid
> DNS lookup delays, it is usually preferable to use an
> IP a
>>> perl -e 'use strict; use warnings; use PVE::ProcFSTools; use Data::Dumper;
>>> print Dumper(PVE::ProcFSTools::parse_proc_mounts());'
>>>
>>
>> $VAR1 = [
>>
>> [
>> ':/backup/proxmox-infra',
>> '/mnt/pve/aurel',
>> 'nfs',
>>
>> 'r
On Fri, May 19, 2017 at 01:59:27PM +0200, Uwe Sauter wrote:
>
> >>
> >> I suspect that something just doesn't send emails in that specific error
> >> case…
> >
> > yes, seems like activate_storage is called very early on to retrieve
> > maxfiles and dumpdir via PVE::API2::VZDump (POST) -> PVE::V
On Fri, May 19, 2017 at 12:49:21PM +0200, Uwe Sauter wrote:
> Am 19.05.2017 um 11:53 schrieb Fabian Grünbichler:
> > On Fri, May 19, 2017 at 11:26:35AM +0200, Uwe Sauter wrote:
> >> Hi Fabian,
> >>
> >> thanks for looking into this.
> >>
> >> As I already mentioned yesterday my NFS setup tries to u
Am 19.05.2017 um 11:53 schrieb Fabian Grünbichler:
> On Fri, May 19, 2017 at 11:26:35AM +0200, Uwe Sauter wrote:
>> Hi Fabian,
>>
>> thanks for looking into this.
>>
>> As I already mentioned yesterday my NFS setup tries to use TCP as much as
>> possible so the only UDP port used / allowed in the
On Fri, May 19, 2017 at 11:26:35AM +0200, Uwe Sauter wrote:
> Hi Fabian,
>
> thanks for looking into this.
>
> As I already mentioned yesterday my NFS setup tries to use TCP as much as
> possible so the only UDP port used / allowed in the NFS
> servers firewall is udp/111 for Portmapper (to allo
Hi Fabian,
thanks for looking into this.
As I already mentioned yesterday my NFS setup tries to use TCP as much as
possible so the only UDP port used / allowed in the NFS
servers firewall is udp/111 for Portmapper (to allow showmount to work).
>> Issue 1:
>> Backups failed tonight with "Error:
On Fri, May 19, 2017 at 10:43:26AM +0200, Uwe Sauter wrote:
> Hi all,
>
> after having succeeded to have an almost TCP-based NFS share mounted (see
> yesterday's thread) I'm now struggling with the backup
> process itself.
>
> Definition of NFS share in /etc/pve/storage.cfg is:
>
> nfs: aurel
>
Hi all,
after having succeeded to have an almost TCP-based NFS share mounted (see
yesterday's thread) I'm now struggling with the backup
process itself.
Definition of NFS share in /etc/pve/storage.cfg is:
nfs: aurel
export /backup/proxmox-infra
path /mnt/pve/aurel
server
13 matches
Mail list logo
