From: "Michael S. Tsirkin" <mst@redhat.com>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
Stefan Hajnoczi <stefanha@redhat.com>,
jelledejong@powercraft.nl, David Miller <davem@davemloft.net>
Subject: Re: TUN_F_UFO change breaks live migration
Date: Tue, 11 Nov 2014 17:57:50 +0200 [thread overview]
Message-ID: <20141111155750.GA17418@redhat.com> (raw)
In-Reply-To: <1415708246.3398.88.camel@decadent.org.uk>
On Tue, Nov 11, 2014 at 12:17:26PM +0000, Ben Hutchings wrote:
> On Tue, 2014-11-11 at 10:58 +0000, Stefan Hajnoczi wrote:
> > Commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4 ("drivers/net: Disable
> > UFO through virtio") breaks live migration of KVM guests from older to
> > newer host kernels:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3d0ad09412ffe00c9afa201d01effdb6023d09b4
> >
> > The problem occurs when a guest running on a host kernel without commit
> > 3d0ad0941 in tun.ko attempts to live migration to a host with commit
> > 3d0ad0941.
> >
> > Live migration fails in QEMU with the following error message:
> >
> > virtio-net: saved image requires TUN_F_UFO support
> >
> > The old host tun.ko advertised support for TUN_F_UFO. The new host
> > tun.ko does not and that's why QEMU aborts live migration. QEMU cannot
> > change the features of a running virtio-net device.
>
> Yes, this is known and was mentioned in the DSA.
>
> > tuxcrafter provided logs from two Debian hosts migrating from
> > 3.2.60-1+deb7u3 to 3.2.63-2+deb7u1:
> >
> > http://paste.debian.net/131264/
> >
> > I haven't investigated enough to suggest a fix, just wanted to bring it
> > to your attention. Soon a lot of people will be hitting this problem as
> > they upgrade their infrastructure and migrate guests - seems like a
> > critical issue.
>
> You can work around this by making macvtap and tun still claim to
> support UFO.
If this is what we want userspace to do, let's just put the
feature flag back?
Basically userspace assumed that features will only
ever be added, never removed, so this change is
breaking it.
> They continue to support it even if it's not advertised
> because the tap features don't reliably get propagated to virtio
> devices.
>
> Ben.
Hmm I don't understand this last sentence.
features are actually reliably propagated to virtio devices.
> --
> Ben Hutchings
> Experience is directly proportional to the value of equipment destroyed.
> - Carolyn Scheppner
next prev parent reply other threads:[~2014-11-11 15:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-11 10:58 TUN_F_UFO change breaks live migration Stefan Hajnoczi
2014-11-11 12:17 ` Ben Hutchings
[not found] ` <1415708246.3398.88.camel@decadent.org.uk>
2014-11-11 15:57 ` Michael S. Tsirkin [this message]
2014-11-11 16:38 ` David Miller
2014-11-11 17:07 ` Ben Hutchings
2014-11-11 17:12 ` [PATCH net] Revert "drivers/net: Disable UFO through virtio" in macvtap and tun Ben Hutchings
2014-11-11 21:33 ` David Miller
2014-11-12 19:02 ` Stefan Hajnoczi
2014-11-13 12:00 ` Jelle de Jong
2014-12-01 9:43 ` Michael S. Tsirkin
2014-12-02 17:44 ` Vlad Yasevich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141111155750.GA17418@redhat.com \
--to=mst@redhat.com \
--cc=ben@decadent.org.uk \
--cc=davem@davemloft.net \
--cc=jelledejong@powercraft.nl \
--cc=kvm@vger.kernel.org \
--cc=stefanha@redhat.com \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).