Ask Your Question

Revision history [back]

Answer is Yes. Let me not question why to do or not do this. Lets assume you have all the info you need to decide that this the right thing for you. What happens then?

Sure you may possibly loose availability and performance if you created your entire Open Stack node on a single VM or Zone on your provider. However, if you spread your VMs across multiple availability zones offered by your service provider, then your availability also should increase.

One other aspect to consider if you hosted the compute node as a VM. This will make the instances launched by the compute node run in a fully emulated qemu --which gets slow. However, if you provider allows nested virtualization, you can get back a bunch of performance. You should also consider another aspect where some software may not support you in nested virtualization cases - You should concerned about this if some software depends on underlying drivers for correct functional operation and not just performance. Now if you're requirements are not high performance but general manageability or even product that can take few delayed execution / IO time then it should work. If you workloads fit into the "cattle" kind (See Pets Vs. Cattle presentation), then it should be no different that hosting on dedicated hardware. Dedicated hardware breaks down too.

Answer is Yes. Let me not question why to do or not do this. Lets assume you have all the info you need to decide that this the right thing for you. What happens then?

Sure you may possibly loose availability and performance if you created your entire Open Stack node on a single VM or Zone on your provider. However, if you spread your VMs across multiple availability zones offered by your service provider, then your availability also should increase.

One other aspect to consider if you hosted the compute node as a VM. This will make the instances launched by the compute node run in a fully emulated qemu --which gets slow. However, if you provider allows nested virtualization, you can get back a bunch of performance. You should also Also consider another aspect where some software may not support you in nested virtualization cases - You should be concerned about this if some software depends on underlying drivers for correct functional operation and not just performance. Now if you're requirements are not high performance but general manageability or even product that can take few delayed execution / IO time then it should work. If you your workloads fit into the "cattle" kind (See Pets Vs. Cattle presentation), then it should be no different that (management wise) than hosting on dedicated hardware. Dedicated hardware breaks down too.too. Its a question of managing the frequency and type of breakdowns in VM and dedicated hardware.

Answer is Yes. Let me not question why to do or not do this. Lets assume you have all the info you need to decide that this the right thing for you. What happens then?

Sure you may possibly loose availability and performance if you created your entire Open Stack node on a single VM or Zone on your provider. However, if you spread your VMs across multiple availability zones offered by your service provider, then your availability also should increase.

One other aspect to consider if you hosted the compute node as a VM. This will make the instances launched by the compute node run in a fully emulated qemu --which gets slow. However, if you your provider allows nested virtualization, you can get back a bunch of performance. Also consider another aspect where some software may not support you in nested virtualization cases - You should be concerned about this if some software depends on underlying drivers for correct functional operation and not just performance. Now if you're requirements are not high performance but general manageability or even product that can take few delayed execution / IO time then it should work. If your workloads fit into the "cattle" kind (See Pets Vs. Cattle presentation), then it should be no different (management wise) than hosting on dedicated hardware. Dedicated hardware breaks down too. Its a question of managing the frequency and type of breakdowns in VM and dedicated hardware.