Hi Gilad/Martin, Thanks for the reply. Let me explain the scenario in details:- Each Host would have local filesystems and can be integrated with oVirt as POSIX filesystems storage. Assume each server can run maximum 6 VMs simultaneously(due to memory/CPU constraints) and we have configured 5 hosts (Node1, Node2....Node5). In the beginning the 5 hosts are being configured in the oVirt engine and there is no VM. Now I create the first VM named VM1 and place it in Node1, from this point oVirt Schedular would decide which other host it would put the replica on. This replica VM1 will be in passive state in another host (Node 2 as per diagram). The same procedure would apply on the other created VMs as well. The role of the oVirt scheduler would be to optimize the placement of VMs in such a way that we can maximize the number of VMs availability in case of host(s) failure. Also it should replicate the delta updates to corresponding passive VMs. As per the scenario in a perfect condition 4 VMs are running in each host providing scope for running 2 extra VMs(maximum 6)in case of other host failures.The underlying local storage have kept 4 extra VMs (QCOW2 disks and config files) from different hosts in addition to the 4 VM disk files for the running VMs. Due to some reason Node2 and Node4 have failed, now the replicated passive VMs for the failed nodes will be started on the remaining nodes. In this case most of the VMs were able to start in different node except VM7 and VM14 as those VMs don't have replicas available in the other running nodes. The maximum availability of the VMs can be calculated using the following formula:- *Total No. of VMs running after node failure = ((Total No. of Nodes) - (No. of failed Nodes)) * (Max. No. of VMs that can run per Node)* The HA VM reservation is an excellent feature no doubt, but I think its only applicable if you have a shared storage underlying(NFS,SAN,Gluster etc..).(Correct me if I'm wrong) And yes GlusterFS does have distributed replicated feature which can replicate VM data in multiple bricks, but in GlusterFS you have to map the replicated bricks during creation and the data can only be replicated between the two (or multiple based on your replication numbers) bricks only. The advantage of this feature would be that you can add standalone nodes(odd/even numbers) in oVirt ecosystem and schedular can place VMs in such a balanced and optimized mode so that maximum number of VMs remain available after N nodes failure from M number of nodes(where M>N) Please put your valuable thoughts regarding the same. Request you to let me know if you need any further clarifications from my side. Thanks Kausik On Thu, Jun 26, 2014 at 6:23 PM, Gilad Chaplik <gchaplik@redhat.com> wrote:

Hi Kausik,

If I understand correctly your question, we do support this flow. In case of failure we migrate highly available VMs to other hosts, but note that there could be a connectivity problem between engine an node, and node can still communicate with the storage, so to avoid that (split brain) you need to have PM configured for that node, or manually confirm that the host has rebooted.

We even added a feature lately (3.4's HA reservation [1]) that indicates whether your HA VMs have enough resources in cluster in case of a node failure.

Thanks, Gilad.

[1] http://www.ovirt.org/Features/HA_VM_reservation

----- Original Message -----

...

From: "kausik pal" <kausikpal.1@gmail.com> To: users@ovirt.org Sent: Tuesday, June 24, 2014 8:06:10 PM Subject: [ovirt-users] Is this kind of VM replication possible using oVirt Schedular

Hi All,

PFA the two diagrams describing placement of the VMs during normal condition and condition after two node failure in 5 node set up (Each Node can host up to 6 VMs due to memory constraints).

My question is whether this kind of VM replication as shown in the attached diagram is possible utilizing oVirt schedular.

The benefits of this kind of replication would be following :-

1. Any number of Hosts/Nodes can participate (Odd/Even) in the infrastructure.

2. We can add any number (odd/even) number of Nodes to re-balance the VM placement.

3. After node failures the Maximum number of VMs that can run on the remaining nodes can be calculated with the following formula:-

Total No. of VMs running after node failure = ((Total No. of Nodes) - (No. of failed Nodes)) * (Max. No. of VMs that can run per Node)

The attached table gives a rough calculation on maximum number VMs that can run after node failures.

Please let me know if you need any further information from my side.

Thanks

Kausik

_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users

----- Original Message -----

From: "kausik pal" <kausikpal.1@gmail.com> To: "Gilad Chaplik" <gchaplik@redhat.com>, msivak@redhat.com Cc: users@ovirt.org Sent: Monday, June 30, 2014 3:42:49 PM Subject: Re: [ovirt-users] Is this kind of VM replication possible using oVirt Schedular

hi Gilad/Martin,

Please let me know if you need any further clarifications from my side.

Thanks Kausik

On Fri, Jun 27, 2014 at 3:18 PM, kausik pal < kausikpal.1@gmail.com > wrote:

Hi Gilad/Martin,

Thanks for the reply.

Let me explain the scenario in details:-

Each Host would have local filesystems and can be integrated with oVirt as POSIX filesystems storage.

Assume each server can run maximum 6 VMs simultaneously(due to memory/CPU constraints) and we have configured 5 hosts (Node1, Node2....Node5).

In the beginning the 5 hosts are being configured in the oVirt engine and there is no VM.

Now I create the first VM named VM1 and place it in Node1, from this point oVirt Schedular would decide which other host it would put the replica on. This replica VM1 will be in passive state in another host (Node 2 as per diagram). The same procedure would apply on the other created VMs as well.

The role of the oVirt scheduler would be to optimize the placement of VMs in such a way that we can maximize the number of VMs availability in case of host(s) failure. Also it should replicate the delta updates to corresponding passive VMs.

As per the scenario in a perfect condition 4 VMs are running in each host providing scope for running 2 extra VMs(maximum 6)in case of other host failures.The underlying local storage have kept 4 extra VMs (QCOW2 disks and config files) from different hosts in addition to the 4 VM disk files for the running VMs.

Due to some reason Node2 and Node4 have failed, now the replicated passive VMs for the failed nodes will be started on the remaining nodes. In this case most of the VMs were able to start in different node except VM7 and VM14 as those VMs don't have replicas available in the other running nodes.

The maximum availability of the VMs can be calculated using the following formula:-

Total No. of VMs running after node failure = ((Total No. of Nodes) - (No. of failed Nodes)) * (Max. No. of VMs that can run per Node)

The HA VM reservation is an excellent feature no doubt, but I think its only applicable if you have a shared storage underlying(NFS,SAN,Gluster etc..).(Correct me if I'm wrong)

And yes GlusterFS does have distributed replicated feature which can replicate VM data in multiple bricks, but in GlusterFS you have to map the replicated bricks during creation and the data can only be replicated between the two (or multiple based on your replication numbers) bricks only.

The advantage of this feature would be that you can add standalone nodes(odd/even numbers) in oVirt ecosystem and schedular can place VMs in such a balanced and optimized mode so that maximum number of VMs remain available after N nodes failure from M number of nodes(where M>N)

Please put your valuable thoughts regarding the same.

Request you to let me know if you need any further clarifications from my side.

Thanks

Kausik

On Thu, Jun 26, 2014 at 6:23 PM, Gilad Chaplik < gchaplik@redhat.com > wrote:

Hi Kausik,

If I understand correctly your question, we do support this flow. In case of failure we migrate highly available VMs to other hosts, but note that there could be a connectivity problem between engine an node, and node can still communicate with the storage, so to avoid that (split brain) you need to have PM configured for that node, or manually confirm that the host has rebooted.

We even added a feature lately (3.4's HA reservation [1]) that indicates whether your HA VMs have enough resources in cluster in case of a node failure.

Thanks, Gilad.

[1] http://www.ovirt.org/Features/HA_VM_reservation

----- Original Message -----

...

From: "kausik pal" < kausikpal.1@gmail.com > To: users@ovirt.org Sent: Tuesday, June 24, 2014 8:06:10 PM Subject: [ovirt-users] Is this kind of VM replication possible using oVirt Schedular

Hi All,

PFA the two diagrams describing placement of the VMs during normal condition and condition after two node failure in 5 node set up (Each Node can host up to 6 VMs due to memory constraints).

My question is whether this kind of VM replication as shown in the attached diagram is possible utilizing oVirt schedular.

The benefits of this kind of replication would be following :-

1. Any number of Hosts/Nodes can participate (Odd/Even) in the infrastructure.

2. We can add any number (odd/even) number of Nodes to re-balance the VM placement.

3. After node failures the Maximum number of VMs that can run on the remaining nodes can be calculated with the following formula:-

Total No. of VMs running after node failure = ((Total No. of Nodes) - (No. of failed Nodes)) * (Max. No. of VMs that can run per Node)

The attached table gives a rough calculation on maximum number VMs that can run after node failures.

Please let me know if you need any further information from my side.

Thanks

Kausik

Hi Kausik, the main issue I see here is that you use local file system, which is a very limited cluster for that host only. This means you will have different considerations as the scheduler runs in the cluster level. So you will need to consider shared storage to begin with and then we can evaluate the rest of the solution.