RE: [Qemu-devel] QEMU Live Migration: arp-like packet patch

[Uri Lublin]

By now (more than two months after I sent it) this patch is less relevant, as 
it is already included in Anthony's updated qemu-live-migration patch.
Is live migration going to be accepted soon ?

Regards,
    Uri.

-----Original Message-----
From: address@hidden on behalf of Uri Lublin
Sent: Wed 24/01/2007 18:36
To: address@hidden
Subject: [Qemu-devel] QEMU Live Migration: arp-like packet patch
 
Hello,

We, kvm developers at Qumranet, have been developing a Live Migration solution
    for qemu (and kvm) too (http://kvm.sourceforge.net/migration.html).
We are working with qemu-0.8.2 and are planning to upgrade to the current 
    qemu CVS.
Anthony Liguori sent patches implementing Live Migration 
    (http://lists.gnu.org/archive/html/qemu-devel/2007-01/msg00245.html).
Some differences are:
  - Anthony's solution uses ssh our solution uses TCP sockets.
  - Anthony's interface is a single qemu-monitor command accepting a uri,
        our interface is a single qemu command accepting a few subcommands.
  - Anthony's solution supports migration start without any preparations,
        our solution requires starting a guest (qemu) on the destination host, 
and
        establish connection before starting the migration.

Naturally, Anthony's solution can be easily enhanced to support most of our 
interface.

Since there is no need for two different migration solutions, we'd like to
    cooperate with Anthony (and with you) and contribute some patches which
    are additions to his solution.
Those patches would be based on Anthony's solution (and have to be applied 
after 
    his patches are applied).

The first patch (attached) is an arp-like packet sent (broadcast) when a 
    migration successfully completes.
The purpose of this packet is to inform network switches that the guest moved.
Although the most known unsolicited packet is the famous "gratuitous arp",  
    we are not sending an arp packet since we do not know the guest's ip 
address,
    and we do not want to receive replies.
Instead we use an ethernet "experimental" packet.
The packet is sent only through tap interfaces.
Our implementation currently supports only linux hosts (adding support for 
    other operating systems is probably/hopefully as easy as changing the 
include
    preprocessor directive).

Regards,
    Uri Lublin.

<<winmail.dat>>