04.10.2019 11:33, 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) > >>> >>> 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. > > 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. > >> 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 fail if bitmap already exists. > > 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. > Why merge? source and destination disks are not merged, by destination is replaced by source... And where from will you have bitmaps in destination? -- Best regards, Vladimir
