On Fri, Oct 20, 2017 at 13:12:59 +0100, Daniel P. Berrange wrote:
> On Fri, Oct 20, 2017 at 01:10:14PM +0200, Pavel Hrdina wrote:
> > On Fri, Oct 20, 2017 at 12:59:51PM +0200, Marc Hartmayer wrote:
> > > Hi all,
> > >
> > > the actual capabilities of QEMU are depending on the host. This
> > > incl
On Fri, Oct 20, 2017 at 01:10:14PM +0200, Pavel Hrdina wrote:
> On Fri, Oct 20, 2017 at 12:59:51PM +0200, Marc Hartmayer wrote:
> > Hi all,
> >
> > the actual capabilities of QEMU are depending on the host. This
> > includes dependencies like which kernel modules are loaded or which
> > kernel par
On Fri, Oct 20, 2017 at 13:15:41 +0200, Marc Hartmayer wrote:
> On Fri, Oct 20, 2017 at 01:10 PM +0200, Pavel Hrdina
> wrote:
> > On Fri, Oct 20, 2017 at 12:59:51PM +0200, Marc Hartmayer wrote:
> >> Hi all,
> >>
> >> the actual capabilities of QEMU are depending on the host. This
> >> includes de
On Fri, Oct 20, 2017 at 01:10 PM +0200, Pavel Hrdina wrote:
> On Fri, Oct 20, 2017 at 12:59:51PM +0200, Marc Hartmayer wrote:
>> Hi all,
>>
>> the actual capabilities of QEMU are depending on the host. This
>> includes dependencies like which kernel modules are loaded or which
>> kernel parameters
On Fri, Oct 20, 2017 at 12:59:51PM +0200, Marc Hartmayer wrote:
> Hi all,
>
> the actual capabilities of QEMU are depending on the host. This
> includes dependencies like which kernel modules are loaded or which
> kernel parameters are used (e.g. kvm.nested). Therefore, after a
> restart we cannot
Hi all,
the actual capabilities of QEMU are depending on the host. This
includes dependencies like which kernel modules are loaded or which
kernel parameters are used (e.g. kvm.nested). Therefore, after a
restart we cannot be sure that the QEMU capabilities remain the same.
How can we solve this
