)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"364beedd257c58b80bed9964722c03aed257b15b","unresolved":false,"context_lines":[{"line_number":11,"context_line":""},{"line_number":12,"context_line":"This patch removes the VIR_MIGRATE_TUNNELLED flag set by default"},{"line_number":13,"context_line":"for live block migration."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"Change-Id: Id8b38b0978cdc80df37cb26bb69d8f4bec5bf766"},{"line_number":16,"context_line":"Closes-Bug: #1441054"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"9aa53dc9_998298ff","line":14,"updated":"2015-04-07 15:34:35.000000000","message":"This probably also needs a DocImpact flag because of this doc:\n\nhttp://docs.openstack.org/admin-guide-cloud/content/section_configuring-compute-migrations.html\n\nIn the kvm block migration case, it says:\n\n\"Configuring KVM for block migration is exactly the same as the above configuration in the section called “Shared storage”, except that NOVA-INST-DIR/instances is local to each host rather than shared. No NFS client or server configuration is required.\"\n\nThat\u0027s not really true because in the shared storage section it says to set the tunneled flag for the live_migration_flag config option - and it also says in the shared storage section that that config option isn\u0027t set by default (which it is).  The docs should probably call out the block_migration_flag config option separately.","commit_id":"5718e2be432f7f2aac44ecea8311d6d1e6fdbde8"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"c9fea20e97977e3344de8cf33106e31d6b2d1838","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Remove tunnel flag for live migration"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"With libvirt release of 1.0.3 (out in MAR 2013), live-migration"},{"line_number":10,"context_line":"switched to a *new* migration scheme under the hood (NBD + QEMU"},{"line_number":11,"context_line":"\u0027drive_mirror\u0027 QMP command[1][2])."},{"line_number":12,"context_line":"With this introduction of NBD-based migration, there"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"fa1b9901_8602873d","line":9,"updated":"2015-08-17 15:34:09.000000000","message":"As jogo pointed out in the comments, we still officially support 0.9.11 so it seems wrong to just drop TUNNELED from the default options.  Wouldn\u0027t it be more prudent to put a version check in the code that uses these options and if you\u0027re using libvirt \u003e\u003d 1.0.3 then warn against using TUNNELED and/or just remove it from the option list?","commit_id":"1e4fe2b6b423b7fff15e3e049b513fdd127ac1e4"}],"nova/virt/libvirt/driver.py":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"df2646d0fd9d136126712c3c5683efcf6194af42","unresolved":false,"context_lines":[{"line_number":151,"context_line":"               help\u003d\u0027Migration flags to be set for live migration\u0027),"},{"line_number":152,"context_line":"    cfg.StrOpt(\u0027block_migration_flag\u0027,"},{"line_number":153,"context_line":"               default\u003d\u0027VIR_MIGRATE_UNDEFINE_SOURCE, VIR_MIGRATE_PEER2PEER, \u0027"},{"line_number":154,"context_line":"                       \u0027VIR_MIGRATE_LIVE, VIR_MIGRATE_TUNNELLED, \u0027"},{"line_number":155,"context_line":"                       \u0027VIR_MIGRATE_NON_SHARED_INC\u0027,"},{"line_number":156,"context_line":"               help\u003d\u0027Migration flags to be set for block migration\u0027),"},{"line_number":157,"context_line":"    cfg.IntOpt(\u0027live_migration_bandwidth\u0027,"}],"source_content_type":"text/x-python","patch_set":1,"id":"9aa53dc9_b92b1c82","side":"PARENT","line":154,"updated":"2015-04-07 15:28:07.000000000","message":"This is the change that added the tunneled flag:\n\nhttps://review.openstack.org/#/c/74600/\n\ndanpb approved it which seems odd if he knows that tunneling doesn\u0027t work with live block migration and is working on a fix for libvirt itself.","commit_id":"9aff3292ce2e60af2f5f8ad866abc2980e97d5bb"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"4231a187d4dca708312909bfc5a628cac8069718","unresolved":false,"context_lines":[{"line_number":151,"context_line":"               help\u003d\u0027Migration flags to be set for live migration\u0027),"},{"line_number":152,"context_line":"    cfg.StrOpt(\u0027block_migration_flag\u0027,"},{"line_number":153,"context_line":"               default\u003d\u0027VIR_MIGRATE_UNDEFINE_SOURCE, VIR_MIGRATE_PEER2PEER, \u0027"},{"line_number":154,"context_line":"                       \u0027VIR_MIGRATE_LIVE, VIR_MIGRATE_TUNNELLED, \u0027"},{"line_number":155,"context_line":"                       \u0027VIR_MIGRATE_NON_SHARED_INC\u0027,"},{"line_number":156,"context_line":"               help\u003d\u0027Migration flags to be set for block migration\u0027),"},{"line_number":157,"context_line":"    cfg.IntOpt(\u0027live_migration_bandwidth\u0027,"}],"source_content_type":"text/x-python","patch_set":1,"id":"7aaa499b_368a8cc0","side":"PARENT","line":154,"in_reply_to":"9aa53dc9_b92b1c82","updated":"2015-04-13 10:12:40.000000000","message":"This approval was a mistake by me originally. It had slipped my mind at the time, that NBD could not be tunnelled with libvirt for block migration. So  adding the TUNNELLED flag was the wrong thing todo in that previous change.\n\nThis is unfortunate because without the TUNNELLED flag migration data will be transmitted in clear-text and so vulnerable to network snooping.\n\nI\u0027m in two minds as to whether we should remove TUNNELLED from both config parameters here, or only from the block migration parameter. On the one hand consistency of operation is desirable for block vs non-block migration. On the other hand it is nice to maximise security where possible for non-block migration by keeping TUNNELLED.  I\u0027m probably leaning slightly more towards the consistency view point though.\n\nSeparately I\u0027m spending the next few months working on QEMU itself to add native support for encryption in migration \u0026 NBD which will solve this problem once \u0026 for all without the need to tunnel anything.\n\n\nOn a side note, I would personally prefer that these config options are killed and Nova just \"do the right thing\" as best it can - there really shouldn\u0027t be a need for the admin to directly set libvirt API constants in this way.  We\u0027d be better off just having a parameter to indicate whether migration should be secure or insecure, and then automatically set the right flags.","commit_id":"9aff3292ce2e60af2f5f8ad866abc2980e97d5bb"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"dc25c7b5623a31c5117df0ee67aeda9b310a3142","unresolved":false,"context_lines":[{"line_number":151,"context_line":"               help\u003d\u0027Migration flags to be set for live migration\u0027),"},{"line_number":152,"context_line":"    cfg.StrOpt(\u0027block_migration_flag\u0027,"},{"line_number":153,"context_line":"               default\u003d\u0027VIR_MIGRATE_UNDEFINE_SOURCE, VIR_MIGRATE_PEER2PEER, \u0027"},{"line_number":154,"context_line":"                       \u0027VIR_MIGRATE_LIVE, VIR_MIGRATE_TUNNELLED, \u0027"},{"line_number":155,"context_line":"                       \u0027VIR_MIGRATE_NON_SHARED_INC\u0027,"},{"line_number":156,"context_line":"               help\u003d\u0027Migration flags to be set for block migration\u0027),"},{"line_number":157,"context_line":"    cfg.IntOpt(\u0027live_migration_bandwidth\u0027,"}],"source_content_type":"text/x-python","patch_set":1,"id":"9aa53dc9_2661093a","side":"PARENT","line":154,"in_reply_to":"9aa53dc9_b92b1c82","updated":"2015-04-08 10:25:52.000000000","message":"Yes,  danpb was right at that time -- because the libvirt version Robert\nCollins tested was using a different migration mechanism. I\u0027ll let danpb\nconfirm (correct/add more details) when he\u0027s back. But I did some more\ndigging this morning and briefly spoke to Michal Privozik, on IRC, who\nadded support for the new NBD-based (and \u0027drive_mirror\u0027) migration[1][2]\nin libvirt:\n   \n  - In 2014, this change to Nova was introduced\n    https://review.openstack.org/#/c/74600/. That worked with TUNNELLED\n    migration, because, at that time, the libvirt version used was 0.9.6\n    (out in SEP 2011) which used a *different* migration scheme (QEMU\n    \u0027migrate -b\u0027 HMP command) under the hood -- in this method, QEMU\n    used a single stream for both memory and storage copying.\n\n    (It\u0027s worth noting that the old-way of migration (\u0027migrate -b\u0027)\n    approach is now legacy.)\n\n  - With libvirt release of 1.0.3 (out in MAR 2013), it switched to a\n    *new* migration scheme under the hood (NBD + QEMU \u0027drive_mirror\u0027 QMP\n    command[1][2]). With this introduction of NBD-based migration, there\n    are two data streams (one for memory, the other for disks), but\n    libvirt was yet not taught how to multiplex two streams into one --\n    consequently, TUNNELLED (which can only deal with single stream)\n    libvirt migration fails.\n\nIIUC (and a QEMU upstream dev confirmed) danpb\u0027s in-progress \nupstream QEMU work \"Universal encryption on QEMU I/O channels\"[3]\n will eventually allow  secure non-tunnelled migration to work.\n\n[1] http://wiki.libvirt.org/page/NBD_storage_migration\n[2] http://libvirt.org/git/?p\u003dlibvirt.git;h\u003d7b7600b -- qemu_migration:\n    Introduce qemuMigrationDriveMirror\n[3] https://lists.gnu.org/archive/html/qemu-devel/2015-02/msg00529.html","commit_id":"9aff3292ce2e60af2f5f8ad866abc2980e97d5bb"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"b9a8c7a999b0e94acdb95afb66677c2b02e0e82a","unresolved":false,"context_lines":[{"line_number":5360,"context_line":"        \"\"\""},{"line_number":5361,"context_line":""},{"line_number":5362,"context_line":"        try:"},{"line_number":5363,"context_line":"            if block_migration:"},{"line_number":5364,"context_line":"                flaglist \u003d CONF.libvirt.block_migration_flag.split(\u0027,\u0027)"},{"line_number":5365,"context_line":"            else:"},{"line_number":5366,"context_line":"                flaglist \u003d CONF.libvirt.live_migration_flag.split(\u0027,\u0027)"}],"source_content_type":"text/x-python","patch_set":1,"id":"9aa53dc9_f61d33be","line":5363,"updated":"2015-04-07 15:23:38.000000000","message":"Since block_migration_flag is a config option, and if we know that tunneled won\u0027t work with live block migration, should we check if it\u0027s in the list (user added it?) and remove/log warning if it\u0027s present?\n\nI\u0027m also wondering how this is passing in the aiocpu job which is running live block migration:\n\nhttp://logs.openstack.org/20/169520/1/check/check-tempest-dsvm-aiopcpu-full/4a86955/console.html.gz#_2015-04-03_19_02_12_731","commit_id":"5718e2be432f7f2aac44ecea8311d6d1e6fdbde8"},{"author":{"_account_id":2888,"name":"Mathieu Rohon","email":"mathieu.rohon@gmail.com","username":"mathieu-rohon"},"change_message_id":"d3aaa0958ca1fc0b7ae7493b99fa147d03a71f36","unresolved":false,"context_lines":[{"line_number":5360,"context_line":"        \"\"\""},{"line_number":5361,"context_line":""},{"line_number":5362,"context_line":"        try:"},{"line_number":5363,"context_line":"            if block_migration:"},{"line_number":5364,"context_line":"                flaglist \u003d CONF.libvirt.block_migration_flag.split(\u0027,\u0027)"},{"line_number":5365,"context_line":"            else:"},{"line_number":5366,"context_line":"                flaglist \u003d CONF.libvirt.live_migration_flag.split(\u0027,\u0027)"}],"source_content_type":"text/x-python","patch_set":1,"id":"9aa53dc9_e09c405f","line":5363,"in_reply_to":"9aa53dc9_d6958fe4","updated":"2015-04-07 18:53:04.000000000","message":"I\u0027m using this param as described in the doc : \n\nlive_migration_uri \u003d qemu+tcp://%s/system\n\nThis is the only main difference I can see between the two configs","commit_id":"5718e2be432f7f2aac44ecea8311d6d1e6fdbde8"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"b17ee34a9bafe8097c5509d86655407af690a1b3","unresolved":false,"context_lines":[{"line_number":5360,"context_line":"        \"\"\""},{"line_number":5361,"context_line":""},{"line_number":5362,"context_line":"        try:"},{"line_number":5363,"context_line":"            if block_migration:"},{"line_number":5364,"context_line":"                flaglist \u003d CONF.libvirt.block_migration_flag.split(\u0027,\u0027)"},{"line_number":5365,"context_line":"            else:"},{"line_number":5366,"context_line":"                flaglist \u003d CONF.libvirt.live_migration_flag.split(\u0027,\u0027)"}],"source_content_type":"text/x-python","patch_set":1,"id":"9aa53dc9_d6958fe4","line":5363,"in_reply_to":"9aa53dc9_f61d33be","updated":"2015-04-07 15:25:07.000000000","message":"Note that the aiocpu job is not changing the defaults:\n\nhttp://logs.openstack.org/20/169520/1/check/check-tempest-dsvm-aiopcpu-full/4a86955/logs/etc/nova/nova.conf.txt.gz","commit_id":"5718e2be432f7f2aac44ecea8311d6d1e6fdbde8"},{"author":{"_account_id":1849,"name":"Joe Gordon","email":"joe.gordon0@gmail.com","username":"jogo"},"change_message_id":"a7e23b7df7ddd5e55a8b5d7aa0b6703b75292428","unresolved":false,"context_lines":[{"line_number":339,"context_line":"    VIR_DOMAIN_PMSUSPENDED: power_state.SUSPENDED,"},{"line_number":340,"context_line":"}"},{"line_number":341,"context_line":""},{"line_number":342,"context_line":"MIN_LIBVIRT_VERSION \u003d (0, 9, 11)"},{"line_number":343,"context_line":"# When the above version matches/exceeds this version"},{"line_number":344,"context_line":"# delete it \u0026 corresponding code using it"},{"line_number":345,"context_line":"MIN_LIBVIRT_DEVICE_CALLBACK_VERSION \u003d (1, 1, 1)"}],"source_content_type":"text/x-python","patch_set":2,"id":"ba3cc151_ff491b32","line":342,"updated":"2015-07-08 02:40:29.000000000","message":"Min libvirt version","commit_id":"1e4fe2b6b423b7fff15e3e049b513fdd127ac1e4"},{"author":{"_account_id":1247,"name":"Mark McLoughlin","email":"markmc@redhat.com","username":"markmc"},"change_message_id":"0d57e27f45768d36fa92ac9bf87808f1ecbfa5b7","unresolved":false,"context_lines":[{"line_number":339,"context_line":"    VIR_DOMAIN_PMSUSPENDED: power_state.SUSPENDED,"},{"line_number":340,"context_line":"}"},{"line_number":341,"context_line":""},{"line_number":342,"context_line":"MIN_LIBVIRT_VERSION \u003d (0, 9, 11)"},{"line_number":343,"context_line":"# When the above version matches/exceeds this version"},{"line_number":344,"context_line":"# delete it \u0026 corresponding code using it"},{"line_number":345,"context_line":"MIN_LIBVIRT_DEVICE_CALLBACK_VERSION \u003d (1, 1, 1)"}],"source_content_type":"text/x-python","patch_set":2,"id":"fa69d971_c8400ea8","line":342,"in_reply_to":"3a7e1126_ad3ef289","updated":"2016-01-04 21:19:04.000000000","message":"I\u0027ve just proposed a patch series to do this. See http://lists.openstack.org/pipermail/openstack-dev/2016-January/083275.html","commit_id":"1e4fe2b6b423b7fff15e3e049b513fdd127ac1e4"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"074517d2d6372e9ac332ce05d2a5669354da4a9e","unresolved":false,"context_lines":[{"line_number":339,"context_line":"    VIR_DOMAIN_PMSUSPENDED: power_state.SUSPENDED,"},{"line_number":340,"context_line":"}"},{"line_number":341,"context_line":""},{"line_number":342,"context_line":"MIN_LIBVIRT_VERSION \u003d (0, 9, 11)"},{"line_number":343,"context_line":"# When the above version matches/exceeds this version"},{"line_number":344,"context_line":"# delete it \u0026 corresponding code using it"},{"line_number":345,"context_line":"MIN_LIBVIRT_DEVICE_CALLBACK_VERSION \u003d (1, 1, 1)"}],"source_content_type":"text/x-python","patch_set":2,"id":"3a7e1126_ad3ef289","line":342,"in_reply_to":"7a2fa921_677858f3","updated":"2015-12-18 15:59:00.000000000","message":"Honestly, I wish we\u0027d just kill off  \u0027live_migration_flag\u0027 and \u0027block_migration_flag\u0027 as config options. We really should not be exposing low level libvirt API flags as admin tunable settings.\n\nNova should really be in charge of picking the correct set of flags for the current libvirt version, and the operation it needs to perform. We might need to add other more sensible config options in their place, eg perhaps a \"live_migration_secure_channel\" to indicate that migration must use encryption, which would imply use of TUNNELLED flag.","commit_id":"1e4fe2b6b423b7fff15e3e049b513fdd127ac1e4"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"932db7bbb9ff1085bb8323ab3fa5066e11ff368c","unresolved":false,"context_lines":[{"line_number":339,"context_line":"    VIR_DOMAIN_PMSUSPENDED: power_state.SUSPENDED,"},{"line_number":340,"context_line":"}"},{"line_number":341,"context_line":""},{"line_number":342,"context_line":"MIN_LIBVIRT_VERSION \u003d (0, 9, 11)"},{"line_number":343,"context_line":"# When the above version matches/exceeds this version"},{"line_number":344,"context_line":"# delete it \u0026 corresponding code using it"},{"line_number":345,"context_line":"MIN_LIBVIRT_DEVICE_CALLBACK_VERSION \u003d (1, 1, 1)"}],"source_content_type":"text/x-python","patch_set":2,"id":"7a2fa921_677858f3","line":342,"in_reply_to":"7a2fa921_e4122662","updated":"2015-10-06 19:38:53.000000000","message":"Because:\n\nhttp://lists.openstack.org/pipermail/openstack-operators/2015-May/007012.html","commit_id":"1e4fe2b6b423b7fff15e3e049b513fdd127ac1e4"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"c9fea20e97977e3344de8cf33106e31d6b2d1838","unresolved":false,"context_lines":[{"line_number":339,"context_line":"    VIR_DOMAIN_PMSUSPENDED: power_state.SUSPENDED,"},{"line_number":340,"context_line":"}"},{"line_number":341,"context_line":""},{"line_number":342,"context_line":"MIN_LIBVIRT_VERSION \u003d (0, 9, 11)"},{"line_number":343,"context_line":"# When the above version matches/exceeds this version"},{"line_number":344,"context_line":"# delete it \u0026 corresponding code using it"},{"line_number":345,"context_line":"MIN_LIBVIRT_DEVICE_CALLBACK_VERSION \u003d (1, 1, 1)"}],"source_content_type":"text/x-python","patch_set":2,"id":"fa1b9901_4681cf8e","line":342,"in_reply_to":"ba3cc151_ff491b32","updated":"2015-08-17 15:34:09.000000000","message":"This code needs to be rebased, but note that our next supported min version in Mitaka is still going to be well below 1.0.3 since it\u0027s 0.10.2:\n\nhttps://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L390","commit_id":"1e4fe2b6b423b7fff15e3e049b513fdd127ac1e4"},{"author":{"_account_id":2750,"name":"Sean Dague","email":"sean@dague.net","username":"sdague"},"change_message_id":"7d326d36f7ff78efc3ecfe19b433e2d4fba40a4e","unresolved":false,"context_lines":[{"line_number":339,"context_line":"    VIR_DOMAIN_PMSUSPENDED: power_state.SUSPENDED,"},{"line_number":340,"context_line":"}"},{"line_number":341,"context_line":""},{"line_number":342,"context_line":"MIN_LIBVIRT_VERSION \u003d (0, 9, 11)"},{"line_number":343,"context_line":"# When the above version matches/exceeds this version"},{"line_number":344,"context_line":"# delete it \u0026 corresponding code using it"},{"line_number":345,"context_line":"MIN_LIBVIRT_DEVICE_CALLBACK_VERSION \u003d (1, 1, 1)"}],"source_content_type":"text/x-python","patch_set":2,"id":"7a2fa921_e4122662","line":342,"in_reply_to":"fa1b9901_4681cf8e","updated":"2015-10-06 19:18:47.000000000","message":"I\u0027m not sure why we can\u0027t bump to 1.0.3 min version for mitaka. Honestly, our upstream test environment is 1.2.2, and I don\u0027t see why we can\u0027t bump up at least to min 1.2.","commit_id":"1e4fe2b6b423b7fff15e3e049b513fdd127ac1e4"}]}