(strange idea) unfriendly migration

(strange idea) unfriendly migration

[George Shuklin]

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).

Here I have two ideas: 

1) We can make HVM domain for Xen (recursive) with PV-only guests. If we
migrate manageable Xen with friendly dom0, it will keep unfriendly
(wild) domU working without knowing about migration.

2) Stop. Do we really needs a big and serious dom0 for 'inner xen'?

Here main idea:

If we create HVM-based overlay for PV-guest to keep thing unchanged, we
can make migration much simpler.

I'm not perfectly know xen internals, but here things I know to be
changed during migration:

1) Wall-clock
2) TSC
3) event channel
4) dom-id
5) vif/vbd entries in xenstore.

And if we make very small and very fine working proxy level between
guest and xen, we can free guest from thinking about Very Nontrivial
Things.

What proxy helper shall do? Let's call every thing changed during
migration a 'migration point'. So, helper shall take every migration
point from xen and dom0 (from xenstore and xen memory areas) and convert
them to matching domU migration point with simple condition: Migration
point of domU shall never be changed during VM power cycle. Note: not a
'domain life' (migrating vm changing one domain to other). Again: values
in xenstore from domU is absolute and shall be never changed.

And from Xen/dom0 point of view proxy helper will do thing smoothly will
full compability with xen without needs to be adopted to different OS'es
and kernel versions (no move war PV vs -xen, etc).

This will make thing very xen-like: we move all logic away from domU to
separate area (note: helper have no more rights than  domU, so no more
code to privileged domain).

Scheme of works:


dom0      ----- XEN  ----- [proxy]
xenstore  ~~~~~~~~~~~~~~~~~[proxy]======[PV-domain]
blktap,etc

---, ~~~~ - changed during migration
========= - permanent during migration.



-----
wBR, George.

Re: [Xen-devel] (strange idea) unfriendly migration

[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.

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

Re: (strange idea) unfriendly migration

[George Shuklin]

В Пнд, 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....