Re: [libvirt] [PATCH v4 5/6] vz: support misc migration options

On Fri, Sep 04, 2015 at 10:42:00AM +0300, Nikolay Shirokovskiy wrote: > > > On 03.09.2015 20:04, Daniel P. Berrange wrote: >> On Wed, Sep 02, 2015 at 03:09:26PM +0300, Nikolay Shirokovskiy wrote: >>> From: nshirokovskiy(a)virtuozzo.com <nshirokovskiy(a)virtuozzo.com&gt; >>> >>> Migration API has a lot of options. This patch intention is to provide >>> support for those options that can be trivially supported and give >>> estimation for other options support in this commit message. >>> >>> I. Supported. >>> >>> 1. VIR_MIGRATE_COMPRESSED. Means 'use compression when migration domain >>> memory'. It is supported but quite uncommon way: vz migration demands that this >>> option should be set. This is due to vz is hardcoded to moving VMs memory using >>> compression. So anyone who wants to migrate vz domain should set this option >>> thus declaring it knows it uses compression. >>> >>> Why bother? May be just support this option and ignore if it is not set or >>> don't support at all as we can't change behaviour in this aspect. Well I >>> believe that this option is, first, inherent to hypervisor implementation as >>> we have a task of moving domain memory to different place and, second, we have >>> a tradeoff here between cpu and network resources and some managment should >>> choose the stratery via this option. If we choose ignoring or unsupporting >>> implementation than this option has a too vague meaning. Let's go into more >>> detail. >>> >>> First if we ignore situation where option is not set than we put user into >>> fallacy that vz hypervisor don't use compression and thus have lower cpu >>> usage. Second approach is to not support the option. The main reason not to >>> follow this way is that 'not supported and not set' is indistinguishable from >>> 'supported and not set' and thus again fool the user. >> >> I think it is reasonable to say that the absence of 'VIR_MIGRATE_COMPRESSED' >> does not mean compression should be turned off. > For me saing so is possible only if impact of compressing/not compressing > is rather insignificant. Otherwise it would be strange that turning on/off > this option does not change anything. For example for live migration > option we can't afford go this way. > > So for clarity i would rather raise an error. One day may be vz > will turn to supporting this option too or default will change. Sure, if you prefer to raise an error that's fine with me.. It just means users will need to always pass --compressed to virsh, but that probably isn't a big deal. >>> 3. VIR_MIGRATE_PERSIST_DEST, VIR_MIGRATE_UNDEFINE_SOURCE. This two comes >>> together. Vz domain are always persistent so we have to demand that options >>> VIR_MIGRATE_PERSIST_DEST and VIR_MIGRATE_UNDEFINE_SOURCE are both set (and >>> this is done just by unsupporting it). >> >> This is a tricky one. It would be nice if we could have just "done the >> right thing" by default with the migrate API, since the default behaviour >> is kind of stupid honestly, but we have to live with backwards compatible >> API semantics now :( >> >> To avoid forcing people to always specify these flags, could you "undo" >> by VZ does by default ? >> >> ie, if VIR_MIGRATE_PERSIST_DEST is *not* passed, then once migration >> has completed, you could use the domainMigrateFinish step to delete >> the config that VZ just created. > This is *not* possible. Vz domains are always persistent. Technically > vz has it own domain configuration file and we convert it to libvirt > xml when asked. Oh right, I understand now. >> Similarly if VIR_MIGRATE_UNDEFINE_SOURCE is *not* passed, then once >> migration completed, you could use the domainMigrateConfirm step >> to re-create the config on the src that VZ just deleted. > This is possible. Eventually this means that we just need to > define domain with the same configuration as migrated one > right after the migration. > > So as one option is possible and the other is not and they are somewhat > paired may be not bother? Or should we take the ignore path as > for compressed so to finish *no-demanding options* strategy? I don't mind which way you choose really. I think allowing the user to not pass UNDEFINE_SOURCE is fairly low priority, since most really /want/ to use UNDEFINE_SOURCE. It only really causes pain for people using the low level virsh tool. For serious apps like OpenStack the default VZ behaviour is what they want all the time.

Regards, Daniel