All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Shuklin <george.shuklin@gmail.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: (strange idea) unfriendly migration
Date: Tue, 02 Nov 2010 00:43:43 +0300	[thread overview]
Message-ID: <1288647824.10627.13.camel@home.desunote.ru> (raw)
In-Reply-To: <20101101101518.GE11016@whitby.uk.xensource.com>

В Пнд, 01/11/2010 в 10:15 +0000, Tim Deegan пишет:
> Hi,
> 
> At 20:07 +0100 on 29 Oct (1288382841), George Shuklin wrote:
> > Good day.
> > 
> > As we all know, xen requires assist from VM to migrate it. If VM will
> > acts wrong during migration, it will crash, or behave strangely until
> > reboot (nice sample - default -xen kernel in lenny).
> > 
> > We need to accept changes in domU during migration: other domain id,
> > new vbd/vif and so on.
> > 
> > This fine until we talks about friendly VM. But if VM is not very
> > friendly? For example, VM's user can upgrade kernel to different -xen,
> > which one working fine with normal mode, but incompatible with
> > migration? (Pretty typical situation for any kind of cloud environment
> > or hosting).
> 
> The user can break their VM's kernel in all sorts of other ways too. :)
> 
> > If we create HVM-based overlay for PV-guest to keep thing unchanged, we
> > can make migration much simpler.
> 
> Nice idea.  I'm not sure it's better than just using HVM for the guest
> in the first place, though - that way the user can install pretty much
> any kernel they want.  And the performance would be worse than either
> plain PV or plain HVM.

Well... Reason I'm takling about such strange solution is many broken
kernels for xen in debian, for example. They works fine and user have no
real intention to broke VM (dd from /dev/zero to root will be more
effective), but update distributive without any bad intention...

HVM have other problem: they do not allow to account disk/network
operation without PV_drivers....

      reply	other threads:[~2010-11-01 21:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-29 19:07 (strange idea) unfriendly migration George Shuklin
2010-11-01 10:15 ` [Xen-devel] " Tim Deegan
2010-11-01 21:43   ` George Shuklin [this message]

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=1288647824.10627.13.camel@home.desunote.ru \
    --to=george.shuklin@gmail.com \
    --cc=xen-devel@lists.xensource.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.