<div>Hi devs,</div><div><br></div><div>Do you test the difference between within and without VIR_MIGRATE_NON_SHARED_INC ?</div><div><br></div><div>When I add <span style="line-height: 1.5;">VIR_MIGRATE_NON_SHARED_INC in block_migration_flags in nova, nova block migration behaves more like a <font color="#ff0000">full</font> copy of disk.</span></div><div><span style="line-height: 1.5;">The disk in destination nodes is large(10GB+) and the process of live migration is slow.</span></div><div><span style="line-height: 1.5;"><br></span></div><div><span style="line-height: 1.5;">However, when I remove  VIR_MIGRATE_NON_SHARED_INC in block_migration_flags in nova, nova block migration behaves more like a </span><font color="#ff0000">incremental</font><span style="line-height: 1.5;"> copy of disk.</span></div><div>The disk in destination nodes is small(10MB-) and the process of live migration is very fast.</div><div><br></div><div>So I was confused about what <span style="line-height: 1.5;">VIR_MIGRATE_NON_SHARED_INC really means.</span></div><div><span style="line-height: 1.5;"><br></span></div><div>Can someone give me some hints?</div><div><br></div><div><div style="color:#909090;font-family:Arial Narrow;font-size:12px">------------------</div><div style="font-size:14px;font-family:Verdana;color:#000;">Luo Gangyi<div><div>luogangyi@cmss.chinamobile.com</div></div></div></div><div> </div><div><div><br></div><div><br></div><div style="font-size: 12px;font-family: Arial Narrow;padding:2px 0 2px 0;">------------------ 原始邮件 ------------------</div><div style="font-size: 12px;background:#efefef;padding:8px;"><div><b>发件人:</b> "Mark McLoughlin";<markmc@redhat.com>;</div><div><b>发送时间:</b> 2016年1月5日(星期二) 凌晨5:12</div><div><b>收件人:</b> "openstack-dev"<openstack-dev@lists.openstack.org>; <wbr></div><div></div><div><b>主题:</b> [openstack-dev] [nova][libvirt] Deprecating the live_migration_flagand block_migration_flag config options</div></div><div><br></div>Hi<br><br>commit 8ecf93e[1] got me thinking - the live_migration_flag config<br>option unnecessarily allows operators choose arbitrary behavior of the<br>migrateToURI() libvirt call, to the extent that we allow the operator<br>to configure a behavior that can result in data loss[1].<br><br>I see that danpb recently said something similar:<br><br>  https://review.openstack.org/171098<br><br>  "Honestly, I wish we'd just kill off  'live_migration_flag' and<br>  'block_migration_flag' as config options. We really should not be<br>  exposing low level libvirt API flags as admin tunable settings.<br><br>  Nova should really be in charge of picking the correct set of flags<br>  for the current libvirt version, and the operation it needs to<br>  perform. We might need to add other more sensible config options in<br>  their place [..]"<br><br>I've just proposed a series of patches, which boils down to the<br>following steps:<br><br>  1) Modify the approach taken in commit 8ecf93e so that instead of <br>     just warning about unsafe use of NON_SHARED_INC, we fix up the <br>     config option to a safe value.<br><br>       https://review.openstack.org/263431<br><br>  2) Hard-code the P2P flag for live and block migrations as <br>     appropriate for the libvirt driver being used.<br><br>     For the qemu driver, We should always use VIR_MIGRATE_PEER2PEER <br>     both live and block migrations. Without this option, you get:<br><br>       Live Migration failure: Requested operation is not valid: direct migration is not supported by the connection driver<br><br>     OTOH, the Xen driver does not support P2P, and only supports <br>     "unmanaged direct connection".<br><br>       https://review.openstack.org/263432<br><br>  3) Require the use of the UNDEFINE_SOURCE flag, and the non-use of<br>     the PERSIST_DEST flag.<br><br>     Nova itself persists the domain configuration on the destination<br>     host, but it assumes the libvirt migration call removes it from<br>the<br>     source host. So it makes no sense to allow operators configure<br>     these flags.<br><br>       https://review.openstack.org/263433<br><br>  4) Add a new config option for tunneled versus native:<br><br>       [libvirt]<br>       live_migration_tunneled = true<br><br>     This enables the use of the VIR_MIGRATE_TUNNELLED flag. We have <br>     historically defaulted to tunneled mode because it requires the <br>     least configuration and is currently the only way to have a <br>     secure migration channel.<br><br>     danpb's quote above continues with:<br><br>       "perhaps a "live_migration_secure_channel" to indicate that <br>        migration must use encryption, which would imply use of <br>        TUNNELLED flag"<br><br>     So we need to discuss whether the config option should express the<br>     choice of tunneled vs native, or whether it should express another<br>     choice which implies tunneled vs native.<br><br>       https://review.openstack.org/263434<br><br>  5) Add a new config option for additional migration flags:<br><br>       [libvirt]<br>       live_migration_extra_flags = VIR_MIGRATE_COMPRESSED<br><br>     This allows operators to continue to experiment with libvirt behaviors<br>     in safe ways without each use case having to be accounted for.<br><br>       https://review.openstack.org/263435<br><br>     We would disallow setting the following flags via this option:<br><br>       VIR_MIGRATE_LIVE<br>       VIR_MIGRATE_PEER2PEER<br>       VIR_MIGRATE_TUNNELLED<br>       VIR_MIGRATE_PERSIST_DEST<br>       VIR_MIGRATE_UNDEFINE_SOURCE<br>       VIR_MIGRATE_NON_SHARED_INC<br>       VIR_MIGRATE_NON_SHARED_DISK<br><br>    which would allow the following currently available flags to be set:<br><br>       VIR_MIGRATE_PAUSED<br>       VIR_MIGRATE_CHANGE_PROTECTION<br>       VIR_MIGRATE_UNSAFE<br>       VIR_MIGRATE_OFFLINE<br>       VIR_MIGRATE_COMPRESSED<br>       VIR_MIGRATE_ABORT_ON_ERROR<br>       VIR_MIGRATE_AUTO_CONVERGE<br>       VIR_MIGRATE_RDMA_PIN_ALL<br><br>  6) Deprecate the existing live_migration_flag and block_migration_flag<br>     config options. Operators would be expected to migrate to using the<br>     live_migration_tunneled or live_migration_extra_flags config options.<br>     During the deprecation period we would invite feedback as to whether<br>     additional config options are needed to cover unanticipated use cases.<br><br>       https://review.openstack.org/263436<br><br><br>Thanks in advance for any feedback.<br><br>I'm going to guess that one piece of feedback will be that some subset<br>of this needs a blueprint (and maybe a spec), and that the blueprint<br>freeze was a month ago, so that subset needs to be punted until after<br>Mitaka? I'd love to be wrong about that, though :)<br><br>Thanks,<br>Mark.<br><br>[1] - https://review.openstack.org/228853<br>[2] - Data loss can occur when you have disk images on shared storage and <br>you specify the VIR_MIGRATE_NON_SHARED_INC or VIR_MIGRATE_NON_SHARED_DISK because during the block migration the disk is copied back over itself<br>while it is in use from another node.<br><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></div>