Re: [ovirt-devel] [!!Mass Mail]Re: VM won't start because of -incoming flag after upgrading to alpha-2
----- Original Message -----
From: "Sven Kieske" <s.kieske(a)mittwald.de>
To: devel(a)ovirt.org
Sent: Wednesday, July 8, 2015 9:08:47 AM
Subject: Re: [ovirt-devel] [!!Mass Mail]Re: VM won't start because of -incoming flag
after upgrading to alpha-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/07/15 13:36, Francesco Romani wrote:
> but if you suspended on qemu and resumed on qemu-kvm-ev, or vice
> versa, then I'm not sure this flow is supported (AFAIR, it isn't).
I wonder why that should not be supported, afaik the only
difference between qemu-kvm and qemu-kvm-ev is the enabled
flag to allow live migrations.
I can't see why this would introduce a flag of "-incoming"
on the qemu command line.
The flag -incoming is for supporting incoming migrations, either
from file (aka resume from suspension) or from another qemu on
another host. So it should'nt be affected by the qemu VS qemu-kvm-ev
split. What I meant is that...
is there a technical reason why this is not supported?
or is this just a "you moved from binary name a to b, so it's not
supported" case, no matter the almost 100% exact same content
within those binarys?
... AFAIR, in the patchset which is part of qemu-kvm-ev, a lot
of devices are disabled for security/safety/auditing reasons,
and new, stable machines are added (rhel*).
When QEMU migrates, again to another qemu or to file, among other
things it needs to freeze and serialize device state.
The format of this device state can change across versions, even though
it usually changes in forward compatible way.
So, the problem *could* be that the resuming QEMU doesn't know how
to handle some device, or cannot understand the stored format.
This is the reason why *I believe* this flow is not supported.
But of course the last word is on the QEMU(-kvm[-ev]) devs.
--
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani