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. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Tim Deegan
2010-Nov-01 10:15 UTC
[Xen-users] Re: [Xen-devel] (strange idea) unfriendly migration
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) _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
В Пнд, 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.... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel