All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Warfield <andrew.warfield@gmail.com>
To: Eric Tessler <maiden1134@yahoo.com>
Cc: xen-devel@lists.sourceforge.net
Subject: Re: XEN migration architecture question
Date: Thu, 20 Jan 2005 21:16:42 +0000	[thread overview]
Message-ID: <eacc82a4050120131611654b50@mail.gmail.com> (raw)
In-Reply-To: <20050120204440.26397.qmail@web41413.mail.yahoo.com>

Hi Eric,

Migration will handle network interfaces and *network attached* block
devices, even under i/o load.  For network devices, an ARP
advertisement is sent indicating the new location of the VM.  We've
tested this a fair bit in cluster environments and are able to migrate
heavily i/o loaded servers very fast.  You may see a few dropped
packets, but TCP will take care of that.  Block devices will see the
backend disconnect when they are suspended, and should reconnect and
reissue any outstanding requests when they resume.

In our migration tests, we generally use network storage.  One
approach that seems to work pretty well is to import GNBD mounts in
domain 0 and export them to the migrating domains --
/dev/gnbd/my-dom-disk will have relevance on both ends of the
migration.

Migration does not currently have explicit support for local block
devices.  It is possible to do, for instance using the block tap to
tunnel the request stream over TCP between the two hosts, it just
isn't clear that it's all that useful -- most people seem to want to
use migration to offload a running VM completely.

hth,
andy.

On Thu, 20 Jan 2005 12:44:40 -0800 (PST), Eric Tessler
<maiden1134@yahoo.com> wrote:
> I have an important question about XEN's migation operation related to the
> XEN block and network back/front drivers.  If I migrate a domain from one
> machine to another in the middle of heavy disk/network activity, what
> happnens to the back/front end XEN drivers? (I see they have suspend/resume
> operations but I don't believe they are being used)  I see that the front
> end drivers are passing machine addresses to the back-end drivers - are
> these pointers somehow still valid when a domain is moved to another
> machine?  Shouldn't the drivers wait until there is no I/O activity before
> being migrated? 
>   
> Thanks, 
> Eric
> 
>  ________________________________
> Do you Yahoo!?
>  Yahoo! Search presents - Jib Jab's 'Second Term' 
> 
>


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

  parent reply	other threads:[~2005-01-20 21:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-20 20:44 XEN migration architecture question Eric Tessler
2005-01-20 21:10 ` Mark Williamson
2005-01-20 21:16 ` Andrew Warfield [this message]
2005-01-20 21:56   ` Jacob Gorm Hansen
2005-01-20 23:28     ` B.G. Bruce
2005-01-20 23:47       ` Jacob Gorm Hansen
  -- strict thread matches above, loose matches on Subject: below --
2005-01-20 22:11 Ian Pratt

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=eacc82a4050120131611654b50@mail.gmail.com \
    --to=andrew.warfield@gmail.com \
    --cc=andrew.warfield@cl.cam.ac.uk \
    --cc=maiden1134@yahoo.com \
    --cc=xen-devel@lists.sourceforge.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 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.