> > > RE your bug, what do you use for a mount point for the nfs storage? > > > > In the log you attached to your bug, it looks like you're using localhost > as > > the nfs mount point. I use a dns name that resolves to the virtual IP > hosted > > by ctdb. So, you're only ever talking to one nfs server at a time, and > failover > > between the nfs hosts is handled by ctdb. > > I also tried your setup, but hit other complications. I used localhost > in an old setup, > previously as I was under the assumption when accessing anything gluster > related, > the connection point only provides the volume info and you connect to any > server in the volume group.
As I understand it, with Gluster's nfs, the server you mount is the only one you're accessing directly, which is why you need to use something else to distribute the load, like round robin dns, with gluster's nfs. > > > > > Anyway, like I said, my main testing rig is now using this configuration, > > help me try and break it. :) > > rm -rf / > > Jokes aside, are you able to reboot a server without losing the VM ? > My experience with ctdb (based on your blog) was even with the > "floating/virtual IP" it wasn't fast enough, or something in the gluster > layer delayed the failover. Either way, the VM goes into paused state and > can't be resumed. I have rebooted my hosts without issue. If I want to reboot the host that's serving the nfs storage, I've stopped ctdb first on that host, to make it hand off the nfs -- I've done this out of caution, but I should try just pulling the plug, too. The main source of VM pausing I've seen is when you have two nodes, one goes down, and the gluster quorum business goes into effect. With my current 3 node, replica 3 setup, gluster stays happy wrt quorum. I'll be sure to post about it if I have problems, but it's been working well for me. Jason _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users