From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5542C47404 for ; Sun, 6 Oct 2019 03:16:52 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 897C8222C0 for ; Sun, 6 Oct 2019 03:16:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 897C8222C0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:59946 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iGx2R-0001Xt-FE for qemu-devel@archiver.kernel.org; Sat, 05 Oct 2019 23:16:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47052) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iGx1D-00011k-1z for qemu-devel@nongnu.org; Sat, 05 Oct 2019 23:15:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iGx1B-000745-EJ for qemu-devel@nongnu.org; Sat, 05 Oct 2019 23:15:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46928) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iGx16-0006y7-FA; Sat, 05 Oct 2019 23:15:28 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8DD68A44ACD; Sun, 6 Oct 2019 03:15:26 +0000 (UTC) Received: from [10.10.120.66] (ovpn-120-66.rdu2.redhat.com [10.10.120.66]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1CC3D19C69; Sun, 6 Oct 2019 03:15:24 +0000 (UTC) Subject: Re: bitmap migration bug with -drive while block mirror runs To: Peter Krempa References: <315cff78-dcdb-a3ce-2742-da3cc9f0ca97@redhat.com> <4bc910ef-0bec-cfd6-89f6-a93d35367218@redhat.com> <9431d242-bfe1-b9db-17d0-6c1a280a05da@virtuozzo.com> <20191002104600.GC6129@angien.pipo.sk> <73dcfdd5-ede2-250e-4680-7c1408c5a3c3@redhat.com> <7b0ea320-4c77-2b0f-7f12-615aa0a6d8cd@virtuozzo.com> <53da72e0-d265-8d0f-e47c-8338c43081e3@redhat.com> <20191004083307.GI6129@angien.pipo.sk> From: John Snow Autocrypt: addr=jsnow@redhat.com; prefer-encrypt=mutual; keydata= mQINBFTKefwBEAChvwqYC6saTzawbih87LqBYq0d5A8jXYXaiFMV/EvMSDqqY4EY6whXliNO IYzhgrPEe7ZmPxbCSe4iMykjhwMh5byIHDoPGDU+FsQty2KXuoxto+ZdrP9gymAgmyqdk3aV vzzmCa3cOppcqKvA0Kqr10UeX/z4OMVV390V+DVWUvzXpda45/Sxup57pk+hyY52wxxjIqef rj8u5BN93s5uCVTus0oiVA6W+iXYzTvVDStMFVqnTxSxlpZoH5RGKvmoWV3uutByQyBPHW2U 1Y6n6iEZ9MlP3hcDqlo0S8jeP03HaD4gOqCuqLceWF5+2WyHzNfylpNMFVi+Hp0H/nSDtCvQ ua7j+6Pt7q5rvqgHvRipkDDVsjqwasuNc3wyoHexrBeLU/iJBuDld5iLy+dHXoYMB3HmjMxj 3K5/8XhGrDx6BDFeO3HIpi3u2z1jniB7RtyVEtdupED6lqsDj0oSz9NxaOFZrS3Jf6z/kHIf h42mM9Sx7+s4c07N2LieUxcfqhFTaa/voRibF4cmkBVUhOD1AKXNfhEsTvmcz9NbUchCkcvA T9119CrsxfVsE7bXiGvdXnzyGLXdsoosjzwacKdOrVaDmN3Uy+SHiQXo6TlkSdV0XH2PUxTM LsBFIO9qXO43Ai6J6iPAP/01l8fuZfpJE0/L/c25yyaND7xA3wARAQABtCpKb2huIFNub3cg KEpvaG4gSHVzdG9uKSA8anNub3dAcmVkaGF0LmNvbT6JAlQEEwECAD4CGwMCHgECF4AFCwkI BwMFFQoJCAsFFgIDAQAWIQT665cRoSz0dYEvGPKIqQZNGDVh6wUCXF392gUJC1Xq3gAKCRCI qQZNGDVh6558D/9pM4pu4njX5aT6uUW3vAmbWLF1jfPxiTQgSHAnm9EBMZED/fsvkzj97clo LN7JKmbYZNgJmR01A7flG45V4iOR/249qAfaVuD+ZzZi1R4jFzr13WS+IEdn0hYp9ITndb7R ezW+HGu6/rP2PnfmDnNowgJu6Dp6IUEabq8SXXwGHXZPuMIrsXJxUdKJdGnh1o2u7271yNO7 J9PEMuMDsgjsdnaGtv7aQ9CECtXvBleAc06pLW2HU10r5wQyBMZGITemJdBhhdzGmbHAL0M6 vKi/bafHRWqfMqOAdDkv3Jg4arl2NCG/uNateR1z5e529+UlB4XVAQT+f5T/YyI65DFTY940 il3aZhA8u788jZEPMXmt94u7uPZbEYp7V0jt68SrTaOgO7NaXsboXFjwEa42Ug5lB5d5/Qdp 1AITUv0NJ51kKwhHL1dEagGeloIsGVQILmpS0MLdtitBHqZLsnJkRvtMaxo47giyBlv2ewmq tIGTlVLxHx9xkc9aVepOuiGlZaZB72c9AvZs9rKaAjgU2UfJHlB/Hr4uSk/1EY0IgMv4vnsG 1sA5gvS7A4T4euu0PqHtn2sZEWDrk5RDbw0yIb53JYdXboLFmFXKzVASfKh2ZVeXRBlQQSJi 3PBR1GzzqORlfryby7mkY857xzCI2NkIkD2eq+HhzFTfFOTdGrkCDQRUynn8ARAAwbhP45BE d/zAMBPV2dk2WwIwKRSKULElP3kXpcuiDWYQob3UODUUqClO+3aXVRndaNmZX9WbzGYexVo3 5j+CVBCGr3DlU8AL9pp3KQ3SJihWcDed1LSmUf8tS+10d6mdGxDqgnd/OWU214isvhgWZtZG MM/Xj7cx5pERIiP+jqu7PT1cibcfcEKhPjYdyV1QnLtKNGrTg/UMKaL+qkWBUI/8uBoa0HLs NH63bXsRtNAG8w6qG7iiueYZUIXKc4IHINUguqYQJVdSe+u8b2N5XNhDSEUhdlqFYraJvX6d TjxMTW5lzVG2KjztfErRNSUmu2gezbw1/CV0ztniOKDA7mkQi6UIUDRh4LxRm5mflfKiCyDQ L6P/jxHBxFv+sIgjuLrfNhIC1p3z9rvCh+idAVJgtHtYl8p6GAVrF+4xQV2zZH45tgmHo2+S JsLPjXZtWVsWANpepXnesyabWtNAV4qQB7/SfC77zZwsVX0OOY2Qc+iohmXo8U7DgXVDgl/R /5Qgfnlv0/3rOdMt6ZPy5LJr8D9LJmcP0RvX98jyoBOf06Q9QtEwJsNLCOCo2LKNL71DNjZr nXEwjUH66CXiRXDbDKprt71BiSTitkFhGGU88XCtrp8R9yArXPf4MN+wNYBjfT7K29gWTzxt 9DYQIvEf69oZD5Z5qHYGp031E90AEQEAAYkCPAQYAQIAJgIbDBYhBPrrlxGhLPR1gS8Y8oip Bk0YNWHrBQJcXf3JBQkLVerNAAoJEIipBk0YNWHrU1AP/1FOK2SBGbyhHa5vDHuf47fgLipC e0/h1E0vdSonzlhPxuZoQ47FjzG9uOhqqQG6/PqtWs/FJIyz8aGG4aV+pSA/9Ko3/2ND8MSY ZflWs7Y8Peg08Ro01GTHFITjEUgHpTpHiT6TNcZB5aZNJ8jqCtW5UlqvXXbVeSTmO70ZiVtc vUJbpvSxYmzhFfZWaXIPcNcKWL1rnmnzs67lDhMLdkYVf91aml/XtyMUlfB8Iaejzud9Ht3r C0pA9MG57pLblX7okEshxAC0+tUdY2vANWFeX0mgqRt1GSuG9XM9H/cKP1czfUV/FgaWo/Ya fM4eMhUAlL/y+/AJxxumPhBXftM4yuiktp2JMezoIMJI9fmhjfWDw7+2jVrx9ze1joLakFD1 rVAoHxVJ7ORfQ4Ni/qWbQm3T6qQkSMt4N/scNsMczibdTPxU7qtwQwIeFOOc3wEwmJ9Qe3ox TODQ0agXiWVj0OXYCHJ6MxTDswtyTGQW+nUHpKBgHGwUaR6d1kr/LK9+5LpOfRlK9VRfEu7D PGNiRkr8Abp8jHsrBqQWfUS1bAf62bq6XUel0kUCtb7qCq024aOczXYWPFpJFX+nhp4d7NeH Edq+wlC13sBSiSHC7T5yssJ+7JPa2ATLlSKhEvBsLe2TsSTTtFlA0nBclqhfJXzimiuge9qU E40lvMWBuQINBFTKimUBEADDbJ+pQ5M4QBMWkaWImRj7c598xIZ37oKM6rGaSnuB1SVb7YCr Ci2MTwQcrQscA2jm80O8VFqWk+/XsEp62dty47GVwSfdGje/3zv3VTH2KhOCKOq3oPP5ZXWY rz2d2WnTvx++o6lU7HLHDEC3NGLYNLkL1lyVxLhnhvcMxkf1EGA1DboEcMgnJrNB1pGP27ww cSfvdyPGseV+qZZa8kuViDga1oxmnYDxFKMGLxrClqHrRt8geQL1Wj5KFM5hFtGTK4da5lPn wGNd6/CINMeCT2AWZY5ySz7/tSZe5F22vPvVZGoPgQicYWdNc3ap7+7IKP86JNjmec/9RJcz jvrYjJdiqBVldXou72CtDydKVLVSKv8c2wBDJghYZitfYIaL8cTvQfUHRYTfo0n5KKSec8Vo vjDuxmdbOUBA+SkRxqmneP5OxGoZ92VusrwWCjry8HRsNdR+2T+ClDCO6Wpihu4V3CPkQwTy eCuMHPAT0ka5paTwLrnZIxsdfnjUa96T10vzmQgAxpbbiaLvgKJ8+76OPdDnhddyxd2ldYfw RkF5PEGg3mqZnYKNNBtwjvX49SAvgETQvLzQ8IKVgZS0m4z9qHHvtc1BsQnFfe+LJOFjzZr7 CrDNJMqk1JTHYsSi2JcN3vY32WMezXSQ0TzeMK4kdnclSQyp/h23GWod5QARAQABiQRbBBgB AgAmAhsCFiEE+uuXEaEs9HWBLxjyiKkGTRg1YesFAlxd/coFCQtV2mQCKcFdIAQZAQIABgUC VMqKZQAKCRB974EGqvw5DiJoEACLmuiRq9ifvOh5DyBFwRS7gvA14DsGQngmC57EzV0EFcfM XVi1jX5OtwUyUe0Az5r6lHyyHDsDsIpLKBlWrYCeLpUhRR3oy181T7UNxvujGFeTkzvLAOo6 Hs3b8Wv9ARg+7acRYkQRNY7k0GIJ6YZz149tRyRKAy/vSjsaB9Lt0NOd1wf2EQMKwRVELwJD y0AazGn+0PRP7Bua2YbtxaBmhBBDb2tPpwn8U9xdckB4Vlft9lcWNsC/18Gi9bpjd9FSbdH/ sOUI+3ToWYENeoT4IP09wn6EkgWaJS3nAUN/MOycNej2i4Yhy2wDDSKyTAnVkSSSoXk+tK91 HfqtokbDanB8daP+K5LgoiWHzjfWzsxA2jKisI4YCGjrYQzTyGOT6P6u6SEeoEx10865B/zc 8/vN50kncdjYz2naacIDEKQNZlnGLsGkpCbfmfdi3Zg4vuWKNdWr0wGUzDUcpqW0y/lUXna+ 6uyQShX5e4JD2UPuf9WAQ9HtgSAkaDd4O1I2J41sleePzZOVB3DmYgy+ECRJJ5nw3ihdxpgc y/v3lfcJaqiyCv0PF+K/gSOvwhH7CbVqARmptT7yhhxqFdaYWo2Z2ksuKyoKSRMFCXQY5oac uTmyPIT4STFyUQFeqSCWDum/NFNoSKhmItw2Td+4VSJHShRVbg39KNFPZ7mXYAkQiKkGTRg1 YesWJA/+PV3qDUtPNEGwjVvjQqHSbrBy94tu6gJvPHgGPtRDYvxnCaJsmgiC0pGB2KFRsnfl 2zBNBEWF/XwsI081jQE5UO60GKmHTputChLXpVobyuc+lroG2YhknXRBAV969SLnZR4BS/1s Gi046gOXfaKYatve8BiZr5it5Foq3FMPDNgZMit1H9Dk8rkKFfDMRf8EGS/Z+TmyEsIf99H7 TH3n7lco8qO81fSFwkh4pvo2kWRFYTC5vsIVQ+GqVUp+W1DZJHxX8LwWuF1AzUt4MUTtNAvy TXl5EgsmoY9mpNNL7ZnW65oG63nEP5KNiybvuQJzXVxR8eqzOh2Mod4nHg3PE7UCd3DvLNsn GXFRo44WyT/G2lArBtjpkut7bDm0i1nENABy2UgS+1QvdmgNu6aEZxdNthwRjUhuuvCCDMA4 rCDQYyakH2tJNQgkXkeLodBKF4bHiBbuwj0E39S9wmGgg+q4OTnAO/yhQGknle7a7G5xHBwE i0HjnLoJP5jDcoMTabZTIazXmJz3pKM11HYJ5/ZsTIf3ZRJJKIvXJpbmcAPVwTZII6XxiJdh RSSX4Mvd5pL/+5WI6NTdW6DMfigTtdd85fe6PwBNVJL2ZvBfsBJZ5rxg1TOH3KLsYBqBTgW2 glQofxhkJhDEcvjLhe3Y2BlbCWKOmvM8XS9TRt0OwUs= Message-ID: <90ec856c-94d3-5819-a93c-243f42492d41@redhat.com> Date: Sat, 5 Oct 2019 23:15:22 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: <20191004083307.GI6129@angien.pipo.sk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.68]); Sun, 06 Oct 2019 03:15:26 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Vladimir Sementsov-Ogievskiy , qemu-devel , Qemu-block , Max Reitz Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 10/4/19 4:33 AM, Peter Krempa wrote: > On Thu, Oct 03, 2019 at 19:34:56 -0400, John Snow wrote: >> On 10/3/19 6:14 AM, Vladimir Sementsov-Ogievskiy wrote: >>> 03.10.2019 0:35, John Snow wrote: >>>> On 10/2/19 6:46 AM, Peter Krempa wrote: >>> ==== > > [...] > > (I'm sorry if I ignored something which might require input in the > trimmed part but I don't have enough mental capacity to follow this > thread fully) > Yeah, understandable -- it's getting a bit long, but I'm trying to make sure I understand the nuance everywhere before I start pursuing a particular solution. I think you caught the important parts in your replies below. >>> >>> If it's a problem for libvirt to keep same node-names, why should we insist? >>> >>> >> >> Is it really a problem? If libvirt requests migration of bitmaps, those >> bitmaps need to go somewhere. Even if it constructs a different graph >> for valid reasons, it should still understand which qcow2 nodes >> correlate to which other qcow2 nodes and name them accordingly. > > Well, no it is not a problem. Since bitmap migration has a migration > capability and libvirt by default disables all unknown migration > capabilities we can deal with it. > > We have measures to transfer state to the destination we can > basically do the equivalent of the explicit mapping but with extra > steps. > > We know where we want to place the bitmap and thus we can configure > those nodes appropriately and generate new names for everything else so > that nothing gets accidentally copied to wrong place. > > My concern is though about the future. Since this is the first instance > of such a migration feature which requires node names it's okay because > we can cheat by naming the destination "appropriately". The problem > will start though if there will be something else bound to the backend > of a disk addressed by node names which will have different semantics. > > In that case we won't be able to cheat again. > OK, I see the concern now. Though we're free to name nodes to achieve the bitmap semantics we want right now, graph reconfigurations in the future might not be able to fit within the same constraints simultaneously. Reasonable concern. Thank you for the illustrative hypothetical. > Let's assume the following example: > > qemu adds a new feature of migrating the qcow2 L2 cache. This will > obviously have different implications on when it can be used than > bitmaps. > > If we'd like to use either of the features but not both together on a > node there wouldn't be a possibility to achieve that. > > The thing about bitmaps is that they are not really bound to the image > itself but rather the data in the image. As long as the user provides a > image with exactly the same contents the VM can use it and the bitmap > will be correct for it. > > We use this in non-shared storage migration where we by default flatten > the backing chain into a new image. In such case a bitmap is still valid > but the cache in the hypothetical example is not valid to be copied over > for the same node name. > > At the very least the nuances of the capability should be documented so > that we don't have to second guess what is going to happen. > OK, understood. >> I don't see why this is actually a terrible constraint. Even in our >> mapping proposal we're still using node-names. >> >> >> So here's a summary of where I stand right now: >> >> - I want an API in QEMU that doesn't require libvirt. >> >> - I want to accommodate libvirt, but don't understand the requirement >> that node-names must be ephemeral. > > As I've outlined above, the node names must not be ephemeral but on the > same note it's then necessary to clarify when they must be stable > accross migration and when they must be different. > > In the above example I'm outlining an image which has the same data but > it's a different image (it was converted for example). In that case the > bitmap migration would imply the same node name, but at the same time > the image is completely different and any other feature may be > incompatible with it. > > The same is possible e.g. when you have multiple protocols to access the > same data are they the same thing and thus warrant the same node name? > or are they different. > > Treating node names as ephemeral has the advantage of not trying to > assume the equivalence of the images on the migration channel and not > having to try to figure out whether they are "euqivalent enough" for the > given feature. > >> >> - I would like to define a set of default behaviors (when bitmap >> migration is enabled) that migrates only bitmaps it is confident it can >> do so correctly and error out when it cannot. > > This requires also defining a set of external constraints when it will > work. Note that they can differ with other features. > >> >> - I'd like to amend the bitmap device name resolution to accommodate the >> drive-mirror case. >> >> - Acknowledging that there might be cases where the defaults just simply >> aren't powerful enough, allow a manual configuration that allows us to >> select or deselect bitmaps and explicitly set their destination node-name. > > This tangentially brings me to another question. In case when the > destination image already contains a bitmap with the same name, will the > migration of bitmaps overwrite it or merge with it? > It will emit an error, currently. > This is again one thing that should be documented. > > In the outlined case of non-shared storage migration libvirt would > obviously prefer merge or having it configurable, but as said, we have > means to work this around by renaming the bitmap temporarily during > migration and then merging it explicitly. > Well, we don't know what bitmap is already there or what semantics it has -- so at the moment we just bail out because we can't tell what's going on. If you find a use case for merge or overwrite, we can add that as a feature, but right now we do the "safe thing". I would have still liked to find a way to migrate bitmap with a "sane default", but because I don't know what I don't know, it might be the case that node-names in the stream that aren't explicitly requested could be a very limiting factor in the future. Sadly, we are already using them -- but perhaps we can find a way to back out of that. So I think the safest thing, given your concern, is: - Any bitmap attached to a root node can be migrated using the root's drive name, if it has one. (This includes the drive-mirror case, if we fix our ability to resolve the root through the filter node.) - Any bitmap that doesn't have a named device or backend at its root should not be migrated without further configuration, because doing so requires node-names in the stream, for which we have a poor understanding of possible future competing constraints. I'm a little sad that this means that blockdev configurations can't be migrated without a much more verbose migration statement. I'm open to suggestions, but it sounds like we do want the ability to specify a migration mapping to keep migration as flexible as possible. I'll sleep on it. --js