[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] hotremoving a disk qmp/hmp
|
From: |
Markus Armbruster |
|
Subject: |
Re: [Qemu-devel] hotremoving a disk qmp/hmp |
|
Date: |
Tue, 18 Nov 2014 18:15:00 +0100 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
William Dauchy <address@hidden> 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 <address@hidden>
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 <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
> 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.