All of lore.kernel.org
 help / color / mirror / Atom feed
From: Uri Lublin <uril@redhat.com>
To: sudhir kumar <smalikphy@gmail.com>
Cc: Michael Goldish <mgoldish@redhat.com>,
	yogi <anantyog@linux.vnet.ibm.com>,
	kvm@vger.kernel.org
Subject: Re: [KVM-AUTOTEST] [PATCH] support for remote migration
Date: Wed, 27 May 2009 17:27:19 +0300	[thread overview]
Message-ID: <4A1D4DC7.4060005@redhat.com> (raw)
In-Reply-To: <a50cf5ab0905242340i22ee1e47nc5e4972c5e1bb2d0@mail.gmail.com>

sudhir kumar wrote:
> Michael,
> any updates on this patch? Are you going to commit this or you have
> any other plans/patch ?
> 

I'm not sure having the inter-host migration is best implemented on the 
autotest-client side. Actually this is one of the few tests I think belong to 
the autotest-server side.

On the other hand it is pretty simple to implement it here. So I think we'd 
better try first implementing it as a server test, and apply it to the client 
side only as a second choice.

A few (minor) problems with it running on the client side:
1. We do not know what the other host is running (what version?, kvm-modules 
loaded? etc.)
2. There may be a conflict between a running local guest running on the remote 
(if it allowed to run tests while being a migration destination), and the remote 
guest.
3. There may be a conflict between two remote guests running a migration test on 
two different hosts.
3. get_free_ports run on the local machine, but expected/assumed to be free on 
the remote machine too.
4. For a migration to be successful, the image(s) must be shared by both hosts. 
On the other hand, when installing a guest OS (e.g. Fedora 8) on both hosts 
(let's assume they both are running fc8_quick) we want different images on 
different hosts.

These are all can be solved easily by non-trivial pretty simple configuration on 
the server. One can configure the "remote" migration to run as a separate tests 
to all other tests.


Regards,
     Uri.



  reply	other threads:[~2009-05-27 14:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <796594249.90621241466107981.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
2009-05-04 19:42 ` [KVM-AUTOTEST] [PATCH] support for remote migration Michael Goldish
2009-05-25  6:40   ` sudhir kumar
2009-05-27 14:27     ` Uri Lublin [this message]
2009-05-27 16:50       ` sudhir kumar
     [not found] <1818401549.327921243244441830.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
2009-05-25  9:53 ` Michael Goldish
2009-05-26  5:18   ` sudhir kumar
     [not found] <1708099165.481031241100420772.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
2009-04-30 14:10 ` Michael Goldish
2009-05-04 14:15   ` yogi
2009-04-30 11:56 yogi
2009-04-30 13:55 ` David Huff

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=4A1D4DC7.4060005@redhat.com \
    --to=uril@redhat.com \
    --cc=anantyog@linux.vnet.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=mgoldish@redhat.com \
    --cc=smalikphy@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.