(strange idea) unfriendly migration

[George Shuklin <george.shuklin@gmail.com>]

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.