public inbox for kvm@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox