[Users] Attach nfs domain to gluster dc

Sergey Gotliv sgotliv at redhat.com
Mon Dec 16 22:59:18 UTC 2013


I apologize for discovering this thread with delay. Let me try to explain.

Attach option indeed missing a possibility to configure NFS options such as nfsver, retrans and timeo 
which by the way available when creating a new storage domain (see the Advanced Parameters section).
I have to check this flow again and see which storage connection we use in order to connect this storage to the new data center. If this is a bug we'll fix it. 

Now about the default NFS version, we are using version 3 because usually customers have a problem to configure NFS server version 4 properly so we allow using version 4 as an advanced option.

Now about your problem:

Option 1:
Can you just create another Export Storage Domain from scratch using advanced parameters I mentioned above in order to configure the NFS version and then just copy the content between these domains manually. 

Option 2:
You can try to create new storage connection with the REST API as explained here: http://www.ovirt.org/Features/Manage_Storage_Connections and then try to re-attach this storage domain again.
Or we can just update storage_server_connections table manually in your database.

I never tried option 2 by myself but it should work. 

Please, feel free to contact me on my direct mail tomorrow sgotliv at redhat.com and I'll walk you through one of these options and we can check you NFS configuration.


----- Original Message -----
> From: "Juan Pablo Lorier" <jplorier at gmail.com>
> To: "Sander Grendelman" <sander at grendelman.com>
> Cc: "users" <users at ovirt.org>
> Sent: Friday, December 13, 2013 1:21:08 PM
> Subject: Re: [Users] Attach nfs domain to gluster dc
> Hi Sander,
> I'll do the changes to the firewall as you mention. I'm running the
> domain in a host as my engine is in a vm with low disk resources. I
> don't know if there's a way to set up the domain automatically with
> ovirt when it's deployed in a host.
> Regards,
> On 13/12/13 06:00, Sander Grendelman wrote:
> > On Thu, Dec 12, 2013 at 5:01 PM, Juan Pablo Lorier <jplorier at gmail.com>
> > wrote:
> > ...
> >> # nfs
> >> -A INPUT -p tcp -m tcp --dport 111   -j ACCEPT
> >> -A INPUT -p tcp -m tcp --dport 38467 -j ACCEPT
> >> -A INPUT -p tcp -m tcp --dport 2049  -j ACCEPT
> >> -A INPUT -p udp -m udp --dport 2049  -j ACCEPT
> >> -A INPUT -p udp -m udp --dport 41729  -j ACCEPT
> >> -A INPUT -p tcp -m tcp --dport 48491  -j ACCEPT
> >> -A INPUT -p udp -m udp --dport 43828  -j ACCEPT
> >> -A INPUT -p tcp -m tcp --dport 48491  -j ACCEPT
> >> -A INPUT -p udp -m udp --dport 47492  -j ACCEPT
> >> -A INPUT -p tcp -m tcp --dport 58837  -j ACCEPT
> > The above rules might break after a reboot.
> >
> > Best practice is to set the normally dynamic nfs ports to fixed
> > values in /etc/sysconfig/nfs and then open those ports in the firewall.
> >
> >> Now I'm changing the settings by overriding the defaults in the domain
> >> and auto negotiating the protocol. This firewall correction may be a
> >> good thing to add in the deploy.
> > Are you doing this on a node or on your engine server?
> >
> > The engine-setup configured both /etc/sysconfig/nfs and iptables for me
> > on my engine server (for the iso domain).
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users

More information about the Users mailing list