public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt@tls.msk.ru>
To: Gleb Natapov <gleb@redhat.com>
Cc: Nils Cant <nils.cant@kangaroot.net>, kvm@vger.kernel.org
Subject: Re: KVM doesn't send an arp announce after live migrating a domain
Date: Wed, 25 Aug 2010 15:36:29 +0400	[thread overview]
Message-ID: <4C75003D.30807@msgid.tls.msk.ru> (raw)
In-Reply-To: <20100825105902.GK10499@redhat.com>

Gleb Natapov wrote:
> On Wed, Aug 25, 2010 at 02:51:31PM +0400, Michael Tokarev wrote:
[]
>> For example, we may teach libvirt or kvm about IP addresses
>> the guest is using, so that kvm will send these ARPs automatically
>> after migration has completed.
[]
>> Kvm is the most natural place to do that, I think, and it's
>> easy to implement there too (it has the tun device which can
>> inject packets on behalf of the guest)   Yes, the configuration
>> will be duplicated somehow, but that's not a big problem, and
>> it will make things much more reliable.
>>
> KVM is certainly not the most natural place to do that. Even gratuitous
> ARP we have today will not work if guest changes mac address. KVM
> couldn't care less about host network protocols. Management may implement
> guest daemon that will take appropriate action to restore networking
> after migration on demand (send gratuitous pigeon if IP over pigeons are
> used by guest).

I mean something else.  When using standard, the most common configuration,
without fancy settings or technologies like IP over pigeons, the most easy
way to do that is in kvm, it should be just about 20 lines of code or so.
Yes that will not work in some complex setups, where in-guest solution will
be needed, but in that case a guest daemon alone wont help, it will need
to run some script to do custom actions.

For the MAC address changes for example -- the solution is simple: don't
change MAC address in guest.  Or if you do, either teach kvm about that
(so it'll send proper ARP), or implement custom solution in guest, or
don't migrate, or live with delays after migration.  There are multiple
choices.

Yet doing it the simplest way (in kvm) will cover some 99% cases, and doing
it as some daemon in the guest will cover that same 99% cases anyway (for
the rest some custom script will be needed).

So I think it's the best to implement it in kvm in the most stright-forward
and easy way.

Yes, some guest notification is probably needed anyway - not only for this
case with networks but also in order to notify guest about, say, resume
from freeze (after loadvm or migrate from file), afrer migration and so
on, so guest can react to such events in a meaningful way.  But this is
in parallel with the ability to send an ARP after migration.

Just IMHO ofcourse.

/mjt

  parent reply	other threads:[~2010-08-25 11:36 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-25  7:52 KVM doesn't send an arp announce after live migrating a domain Nils Cant
2010-08-25  8:37 ` Michael Tokarev
2010-08-25  8:43   ` Gleb Natapov
2010-08-25 10:51     ` Michael Tokarev
2010-08-25 10:59       ` Gleb Natapov
2010-08-25 11:07         ` Gleb Natapov
2010-08-25 11:36         ` Michael Tokarev [this message]
2010-08-25 12:15           ` Gleb Natapov
2010-08-25  8:38 ` Gleb Natapov
2010-08-25  9:21   ` Nils Cant
2010-08-25 10:40     ` Avi Kivity
2010-08-25 10:52       ` Daniel P. Berrange
2010-08-25 11:05         ` Avi Kivity
2010-08-25 11:15           ` Daniel P. Berrange
2010-08-25 11:30             ` Avi Kivity
2010-08-25 11:36               ` Daniel P. Berrange
2010-08-25 11:38                 ` Avi Kivity
2010-08-25 11:42                   ` Daniel P. Berrange
2010-08-25 11:59                     ` Avi Kivity

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=4C75003D.30807@msgid.tls.msk.ru \
    --to=mjt@tls.msk.ru \
    --cc=gleb@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=nils.cant@kangaroot.net \
    /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