search

stepping-stone / configuration-overlay

An overlay for package configuration files to provide customized default configurations and configuration templates for further deployment.
0 stars 1 forks source link

Turn nested virtualization on #3

Open meichenberger opened 10 years ago

meichenberger commented 10 years ago

Manuel tests have been successful. Please turn nested virtualization on. The corresponding documentation: http://wiki.stoney-cloud.org/index.php/stoney_cloud:_Nested_virtualization

dev-zero commented 10 years ago

I would be careful with that. With the current VM CPU configuration (which is copying almost every flag available/capability) every guest will be able to do nested virtualization. Since there is still a lot of overhead involved and the feature not widely tested, this could possibly be used for a DoS. Therefore I would recommend to enable it in the host, but filter out the flag for the guest CPUs for now.

meichenberger commented 10 years ago

Sounds good. The next questions is:

Once we know this, we can define our provider policy towards our customers (who is allowed to turn nested virtualization on).

dev-zero commented 10 years ago

we currently specify the following in the XML (the domain definition "template") to copy all available host CPU features to the guest:

  <cpu mode='host-model'>
    <model fallback='allow'/>
  </cpu>

If we want to be able to enable nested virtualization on a per-VM basis based on the current principle, we have to restrict the flags:

  <cpu mode='host-model'>
    <model fallback='allow'/>
    <feature policy='disable' name='vmx'/>
    <feature policy='disable' name='svm'/>
  </cpu>

... and then toggle between "disable" and "optional" for "vmx" and "svm".

More info: https://www.berrange.com/posts/2010/02/15/guest-cpu-model-configuration-in-libvirt-with-qemukvm/

A different way would be to specify a more basic CPU instead and add flags on an as-needed basis. This would most probably be the cleaner way, but requires a lot of additional attributes and a corresponding model in the LDAP and the management code. Querying the VM node CPUs flags can be done via libvirt, but we would have to replicate this info in the LDAP, do checks, decide what to expose, how, etc...