On Fri, Sep 07, 2012 at 01:29:25PM +0200, Ján Tomko wrote:
On 09/07/12 05:25, Daniel Veillard wrote:
>
> The problem is that libvirt and qemu releases are a priori not
> tied, doing what you suggest would mean to try to guess the actual
> qemu version used by the guest and then switch on or off, which would
> somehow be at odd with the overall driver configuration.
> This also raises the point of the semantic of -sandbox, the code
> assumes that if it is not present then sandboxing is off, and if
> it is present sandboxing is on, now what you say seems to imply that
> sandboxing is on in 1.3 if not present. If right then we need to instead
> do something like -sandbox=off to make sure we propagate the setting
> assuming the qemu.conf explicitely states sandbox=0
>
> So we are I think in a tristate configuration:
> - sandbox=0 in qemu.conf
> and we need to force it off if supported
> - sandbox=1 in qemu.conf
> and we need to force it on if supported
> - commented out in qemu.conf
> fallback to the qemu for that guest default
>
> Apparently currently -sandbox takes no arguments, any chance to
> suport for -sandbox=off before 1.3 ? Because otherwise the global
> settings of libvirt qemu driver will conflict with qemu default setting.
>
> Daniel
>
-sandbox does require an argument, either on or off, so that tri-state
configuration is doable at the moment.
Ah, excellent !
I don't think having it on by default is a good idea at this time
- I
had to add a few syscalls to the whitelist to get it working for me
before posting the patch, but somehow I managed to break it since.
We can try to keep commented out then, but we won't get much testing
then ...
I'll look into those tests/qemuhelp*.
thanks !
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit
http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine
http://rpmfind.net/
http://veillard.com/ | virtualization library
http://libvirt.org/