On Thu, Mar 17, 2011 at 11:47 PM, Rajagopal Swaminathan <raju rajsand gmail com>
On 3/17/11, C.D. <firstname.lastname@example.org> wrote:
> I'm not trying to bash gfs2, actually I would definitely prefer it over
> ocfs2 anytime, however it seems it doesn't work well with VM for some
> I think this should be investigates by someone at RH possibly because theyI am not an employee of Redhat.
> are the driving force behind both KVM, libvirt, the cluster soft and gfs2.
1. As the fastest measure, turn off atime (if on) while remounting
GFS2 and you will immediately notice a zing in performance.
I always mounted with quota=off,noatime,nodiratime , but with them on or off there wasn't any difference.
2. Why would one use GFS2 to store VM? In the absence of CLVM not
offering LUNs on which VMs are stored.
I never said I used GFS2 to store VM. I used GFS2 as a shared storage FS inside VMs. I have a shared LUN exported through the SAN and through the Fabrics switches with multipathing (the host takes care of that). I have a mpath pool in libvirtd and friendly names = off in multipath.conf, so I see the WWIN of each LUN inside virsh/virt-manager. I have all LUNS in all storage groups of each VM host system so I can do migration, but this doesn't seem as the proper place for such discussion.
What I set up was 2 (or more, but in this specific setup it was 2) VMs, each has a LUN that uses for the root partition. And those 2 VMs also share one LUN that I set up with clvmd and gfs2 where I share files between those 2 VMs. All the cluster stuff is working inside the VMs (the guests), the host doesn't know about the cluster, clvmd or gfs2, nor it should know or care about what is going on inside the VMs that are runing atop of it. In this specific scenario those 2 VMs are running web servers and this is the directory with all the files they serve. I hope this sheds some light on my exact setup.
I understand that step 2 may not be feasible if the system is in
production (Well, unless you know that lovely qemu-convert command for
handlink disk images or something like that and dd incantations which
I can't off had remember).
But live storage migration is another issue altogether. I haven't had
a suitable opportunity to cut my teeth in the RHEV Cloud as yet. So no
comments on it from me as yet.
Live storage migration is a non-issue inside my private cloud, as I already solved that with libvirtd, multipathing, the SAN, the SAN switches, etc. It took suprisingly not more than 3 or 4 days of poking around and reading sources, docs and libvirt devel mailing list and I was able to build stable and high performing solution from the ground up on top of RH technology (which I happen to love).
Welcome to the Wonderful world of Redhat HA+VM ! (Its not RHEV please.
RHEV is another, well, lovely and cuddly, beast altogether)
Get the HA right first, then go for virt during rollouts.
At this point I think I'll stay away from RH HA solutions inside VMs. It's too much hastle and surprisingly sparse documentation from RH. As most of my machines are running something that can be load balanced and HA set up through nginx I would probably go again that way and would try some CARP on some of the VMs. But that is something for the next stage of my setup.
Linux-cluster mailing list
Linux-cluster redhat com