William Dauchy <will...@gandi.net> writes: > On Nov18 15:22, Markus Armbruster wrote: >> This is block backend "disk1". > > yes indeed. > >> I presume you're deleting the device using backend "disk1". > > yes > >> What kind of device is this? PCI, perhaps? >> Please show us a complete QMP conversation. > > Here it is: > > live vm with one disk: > > (QEMU) query-block > { u'return': [ { u'device': u'disk0', > u'inserted': { u'backing_file_depth': 0, > u'bps': 0, > u'bps_rd': 0, > u'bps_wr': 0, > u'detect_zeroes': u'off', > u'drv': u'raw', > u'encrypted': False, > u'encryption_key_missing': False, > u'file': u'/dev/sda', > u'image': { u'actual-size': 0, > u'dirty-flag': False, > u'filename': > u'/dev/sda', > u'format': u'raw', > u'virtual-size': > 3221225472}, > u'iops': 0, > u'iops_rd': 0, > u'iops_wr': 0, > u'ro': False}, > u'io-status': u'ok', > u'locked': True, > u'removable': True, > u'tray_open': False, > u'type': u'unknown'}]} > > hotplugging one disk: > > (QEMU) blockdev-add > with > {'options' : { > 'driver': 'raw', > 'id': 'disk1', > 'file': { > 'driver': 'file', > 'filename': /dev/sdb, > } > }} > > (QEMU) device_add > with: > { > 'driver': 'scsi-hd', > 'id': 'disk1',
Using the same ID for different things currently works, but it's awfully confusing. Please don't :) > 'drive': 'disk1', > 'scsi-id': 1, > 'removable': 'on', > 'dpofua': 'off' > } > > (QEMU) query-block > { u'return': [ { u'device': u'disk0', > u'inserted': { u'backing_file_depth': 0, > u'bps': 0, > u'bps_rd': 0, > u'bps_wr': 0, > u'detect_zeroes': u'off', > u'drv': u'raw', > u'encrypted': False, > u'encryption_key_missing': False, > u'file': u'/dev/sda', > u'image': { u'actual-size': 0, > u'dirty-flag': False, > u'filename': > u'/dev/sda', > u'format': u'raw', > u'virtual-size': > 3221225472}, > u'iops': 0, > u'iops_rd': 0, > u'iops_wr': 0, > u'ro': False}, > u'io-status': u'ok', > u'locked': True, > u'removable': True, > u'tray_open': False, > u'type': u'unknown'},, > { u'device': u'disk1', > u'inserted': { u'backing_file_depth': 0, > u'bps': 0, > u'bps_rd': 0, > u'bps_wr': 0, > u'detect_zeroes': u'off', > u'drv': u'raw', > u'encrypted': False, > u'encryption_key_missing': False, > u'file': u'/dev/sdb', > u'image': { u'actual-size': 0, > u'dirty-flag': False, > u'filename': > u'/dev/sdb', > u'format': u'raw', > u'virtual-size': > 3221225472}, > u'iops': 0, > u'iops_rd': 0, > u'iops_wr': 0, > u'ro': False}, > u'io-status': u'ok', > u'locked': True, > u'removable': True, > u'tray_open': False, > u'type': u'unknown'}]} > > hotremoving disk1: > > (QEMU) device_del > with: > {'id': 'disk1'} Since you still didn't provide your *complete* QMP conversation, you leave me guessing what device_del did. I guess device_del succeeded, and you got a DEVICE_DELETED event. This is the kind of information I was looking for: $ rlwrap -H ~/.qmp_history socat UNIX:/work/armbru/images/test-qmp STDIO {"QMP": {"version": {"qemu": {"micro": 91, "minor": 1, "major": 2}, "package": ""}, "capabilities": []}} { "execute": "qmp_capabilities" } {"return": {}} { "execute": "blockdev-add", "arguments": {'options' : {'driver': 'raw', 'id': 'disk1', 'file': {'driver': 'file', 'filename': '/dev/sdb'}}} } {"error": {"class": "GenericError", "desc": "could not open disk image disk1: Could not open '/dev/sdb': Permission denied"}} Block backends created with drive_add get destroyed when a device using it gets destroyed, unlike any other backend. We refrained from bringing this wart forward to blockdev-add. Thus, the backend is still around: > (QEMU) query-block > { u'return': [ { u'device': u'disk0', > u'inserted': { u'backing_file_depth': 0, > u'bps': 0, > u'bps_rd': 0, > u'bps_wr': 0, > u'detect_zeroes': u'off', > u'drv': u'raw', > u'encrypted': False, > u'encryption_key_missing': False, > u'file': u'/dev/sda', > u'image': { u'actual-size': 0, > u'dirty-flag': False, > u'filename': > u'/dev/sda', > u'format': u'raw', > u'virtual-size': > 3221225472}, > u'iops': 0, > u'iops_rd': 0, > u'iops_wr': 0, > u'ro': False}, > u'io-status': u'ok', > u'locked': True, > u'removable': True, > u'tray_open': False, > u'type': u'unknown'},, > { u'device': u'disk1', > u'inserted': { u'backing_file_depth': 0, > u'bps': 0, > u'bps_rd': 0, > u'bps_wr': 0, > u'detect_zeroes': u'off', > u'drv': u'raw', > u'encrypted': False, > u'encryption_key_missing': False, > u'file': u'/dev/sdb, > u'image': { u'actual-size': 0, > u'dirty-flag': False, > u'filename': > u'/dev/sdb', > u'format': u'raw', > u'virtual-size': > 3221225472}, > u'iops': 0, > u'iops_rd': 0, > u'iops_wr': 0, > u'ro': False}, > u'io-status': u'ok', > u'locked': False, > u'removable': True, > u'tray_open': False, > u'type': u'unknown'}]} > > So now I have locked == False but I don't know how to clean the object > with QMP API. > so... > switching to HMP API: > > (QEMU) info block > disk0: /dev/sda (raw) > Removable device: locked, tray closed > > disk1: /dev/sdb (raw) > Removable device: not locked, tray closed > > (QEMU) drive_del disk1 > (QEMU) info block > disk0: /dev/sda (raw) > Removable device: locked, tray closed Looks like you're using an old version of QEMU. drive_del has been fixed to refuse touching a backend created with blockdev-add: commit 48f364dd0ba8d6323ee9ac2b35996eef667bac39 Author: Markus Armbruster <arm...@redhat.com> Date: Thu Sep 11 16:45:39 2014 +0200 blockdev: Refuse to drive_del something added with blockdev-add For some device models, the guest can prevent unplug. Some users need a way to forcibly revoke device model access to the block backend then, so the underlying images can be safely used for something else. drive_del lets you do that. Unfortunately, it conflates revoking access with destroying the backend. Commit 9063f81 made drive_del immediately destroy the root BDS. Nice: the device name becomes available for reuse immediately. Not so nice: the device model's pointer to the root BDS dangles, and we're prone to crash when the memory gets reused. Commit d22b2f4 fixed that by hiding the root BDS instead of destroying it. Destruction only happens on unplug. "Hiding" means removing it from bdrv_states and graph_bdrv_states; see bdrv_make_anon(). This "destroy on revoke" is a misfeature we don't want to carry forward to blockdev-add, just like "destroy on unplug" (commit 2d246f0). So make drive_del fail on anything added with blockdev-add. We'll add separate QMP commands to revoke device model access and to destroy backends. Signed-off-by: Markus Armbruster <arm...@redhat.com> Signed-off-by: Kevin Wolf <kw...@redhat.com> > Is there a way to do the same with QMP commands? You can't destroy a backend created with blockdev-add, yet. I hope to have blockdev-del in 2.3. My advice is to stick to drive_add and drive_del for now. Not in QMP, so you need to use HMP. You can do that in QMP with human-monitor-command.