when you;re talking about hundreds of hosts, it makes more sense to have a controller cluster, and not keep the controller a VM. However, for smaller deployments, the engine can be a VM within it's own setup, that will take an extra step to setup: http://www.ovirt.org/Hosted_Engine_Howto

are you able to go online, e.g. ping 8.8.8.8 ?

The classic datacentre is a bunch of hosts and controllers, plus a SAN. If you prefer to use the servers' disks instead, you can either go with local storage (and lose some of the nicer features, like quick live migration), or wait for hyperconverged setup support, the use gluster when it comes. Shouldn't be long. For details - subscribe and email users@ovirt.org

Network is unreachable.


Ok, so you mean keeping a physical cluster just for the controller? I think that's overboard for my personal project but I can see why that's necessary for larger deployments.

Man this is so cool. Thanks for your help.

Edit: The size of my deployment will be 2 physical hosts with a steady stream of data moving between them so that they're 99.99 identical at all times. Everything else will be VM's. I will set up another host to act as the controller if needed, but then I need HA for the controller host too. Sigh.. this could get expensive lol.

Proper datacenters are expensive. But for two hosts, you can easily go with hosted engine, and if you really have to use the internal storage, you could do something silly, like
1. set up drbd for replication between the two hosts
2. export the drbd backed partition/LV via iscsi from both nodes
3. discover the iscsi share using both IPs, so you can have multipath detect both hosts, and automatically failover IOs if one host goes down.

You will lose half the disk space, since you're replicating, and you probably won't be able to scale this solution out or up, but it's an idea good enough for a testbed

Does this mean that the VM will use iscsi multipath target on an active-passive mode or active-active?
If active-active, does iscsi multipath talks to drdb to avoid data corruption?

I wouldn't touch a/a drbd with a stick

The idea would be to have an a/p backend, and if drbd fails over, iscsi would have at least one usable path left. Of course for a demo setup all this is unnecessary and HA isn't a requirement, but the o/p asked for it.

BTW, instead of iscsi, NFS can be exported from the DRBD backed volume, will also work, but will require manual failover for a secondary IP to become usable

What would you use for a clustered filesystem?
I use AoE a lot, but now that coraid went TITSUP I might consider iscsi (can't do a RAID5 with drdb only RAID1).

My smallest system is a 3 host cluster: I export one of the drives of each host using AoE then, at each host, I setup a RAID5 with one local drive and 2 AoE drives (one from each of the other hosts) then slap OCFS2 on the RAID5.
All 3 hosts are active and have r/w access to that volume, where I keep the .xml files and the virtual HD images for all VMs (each host runs 4 or 5 VMs).
Any one of the hosts can die and the other two take care of whatever VMs it was running, seamlessly.
I guess I can use iscsi instead of AoE, but wanted to know what you use

@biosboy4, sorry if I'm hijacking your thread, but I think that this might help you decide what kind of setup you want to go with

I would rather avoid clustered FS like the plague. If you absolutely must, NFS makes much more sense, because you don't need to deal with locking and failovers and STONITH and other wonders, it just works. AoE was deadborn, it was obvious because iSCSI just made more sense and had an easy onramp for the enterprise folks, who didn't deal much on IDE anyway.

the things people would do, just to avoid using glusterfs and ceph

So... you just use a SAN and hide the inner workings of shared storage?
Gotcha.
iscsi it is, then. Thanks.
Yeah, some people don't use redhatish distros and have no "next, next, finish" GUI available to setup things like glusterfs and ceph.
My setup "looks" complex, until you try to make glusterfs and ceph work on Slackware

I mostly use RHEV for VMs, and RHEV doesn't use a clustered FS, instead if uses LVM with it's own access management system. This lets RHEV run clusters of hundreds of hosts, and never run into typical scsi3-PR bottlenecks

well, I typically need things to work, I don't have the time to sit around compiling and tweaking every knob. For that, out of the box distros just make more sense. Slackware is great for learning the inner workings of a system, but running a cluster of servers on it, especially a cluster that needs to always be up to date and dynamically change - nightmare.