libvirt supports several storage backends[1] for hosting the image on a different server.

We have 6 servers running about 40 VMs. Up to now we use local storage. To minimize the downtime we want to use a remote storage backend.

Operating System: Linux (different distributions).

Up to now, we use virt-manager and virsh to manage our VMs.

I am unsure which step would be the best for a better VM infrastructure.

Update: Explanation of "better": If a physical server fails, we need to open the chassis and move the hard disks to an other server. "better" in this case is, that we can switch faster if a physical server fails.

According to the web page of libvirt these remote storage solutions are available.

  • iSCSI backend
  • RBD (RADOS Block Device) backend
  • Sheepdog backend
  • Gluster backend
  • NFS

Which backend would be good for a small VM count (6 server, 40 VMs)?

[1] http://libvirt.org/storage.html

  • How do you define "better"? You'll lose sequential performance in most of those solutions; a tradeoff for potentially-better resiliency. – ewwhite Jan 6 '14 at 13:48
  • 1
    You left out the NFS backend from your list. – sciurus Jan 6 '14 at 15:01
  • @sciurus That would be too simple ;) – ewwhite Jan 6 '14 at 15:02
  • I updated the question: "better" means: small downtime, if a physical server fails. We don't need a automated solution. – guettli Jan 6 '14 at 15:02
  • Also, multipath is not a remote backend. – sciurus Jan 6 '14 at 15:04

With 6 servers and a storage backend, I'd move all of this to RHEV or oVirt - managing the entire infrastructure will be so much easier, and storage management will be reduced to a couple of clicks/api calls.

Having said that, I'd go with iSCSI - it can provide real multipathing and redundancy, block level management is simple (especially if you use RHEV/oVirt) but a clustered FS or LVM is also not a big deal.

If you have no multipathing in place, stick to NFS - it's the simplest solution with no need for clustered FS

| improve this answer | |
  • What about the drop in performance by going from local disk to iSCSI? – ewwhite Jan 6 '14 at 16:49
  • The t/s is going for a network based storage solution anyway – dyasny Jan 6 '14 at 20:11
  • @dyasny oVirt looks good. Would be OpenStack a good choice, too? Or is our setup to small for OpenStack? – guettli Jan 7 '14 at 8:39
  • That would depend. Openstack is good for large scale deployments, where you can expand the system infinitely, while oVirt cluster size is limited to 200 hosts (you can have lots of clusters though). oVirt provides more features and is more advisable if you're managing a datacenter of your own, openstack is geared towards a cloud-like deployment. And of course, openstack is harder to setup and maintain, much harder – dyasny Jan 7 '14 at 14:58

Gluster (Libgfapi) and replica 2. You can run glusterd on your six server, as a result - distributed fault-tolerant storage.

| improve this answer | |
  • Could you elaborate more on why using gluster addresses the OP's needs? – Castaglia Mar 9 '16 at 22:10
  • Sorry, English is not my native language, I did not understand your question – Sergey Ovsienko Mar 10 '16 at 9:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.