On Thu 22 Oct 2015 01:25:05 PM CEST, Kevin Wolf wrote: >> But there's this case that is not so obvious. It involves the new >> 'blockdev-snapshot' command I'm working on: >> >> - blockdev-add id=drive0 node-name=node0 file=hd0.qcow2 >> - qemu-img create -f qcow2 -b hd0.qcow2 overlay0.qcow2 >> - blockdev-add node-name=overlay0 file=overlay0.qcow2 >> - blockdev-snapshot node=hd0 overlay=overlay0 >> >> At this point you have drive0 with overlay0 inserted, and hd0 as its >> backing image. All these operation will fail: >> >> - blockdev-del id=drive0 because overlay0 has two references >> (monitor and block backend) >> - blockdev-del node=overlay0 for the same reason >> - blockdev-del node=hd0 because it's a backing image >> >> In order to delete all this you need to: >> >> - eject device=drive0 overlay0 has one reference left >> - blockdev-del id=drive0 >> - blockdev-del node=overlay0 this deletes hd0 as well >> >> Does this make sense, or do we need to rethink the semantics a bit more? > > Well, it's consistent with what you described above. > > The confusing part might be that you could blockdev-del id=drive0 > originally, but after taking the snapshot it doesn't work any > more. The only way I can see to remove this effect is that you always > need to eject the BDS first, even if its only reference is from the BB > that is going to be deleted. > > I guess that would be even clearer rules, but of course it also means > that it's a bit more cumbersome to use. If it helps avoiding bugs in > management tools, it might be worth it.
That would be a good reason to force the user to eject the media first. Note however that in this case you would still need to delete overlay0 manually, as it would still have the monitor reference. However if the snapshot is created using blockdev-snapshot-sync that problem does not exist because that extra reference is not there. > But again, I'd like to hear a libvirt opinion from Eric here. Sure, me too. Berto
