aboutsummaryrefslogtreecommitdiff
path: root/tests/qemu-iotests/087.out
AgeCommit message (Collapse)Author
2015-10-23blockdev: Allow creation of BDS trees without BBMax Reitz
If the "id" field is missing from the options given to blockdev-add, just omit the BlockBackend and create the BlockDriverState tree alone. However, if "id" is missing, "node-name" must be specified; otherwise, the BDS tree would no longer be accessible. Many BDS options which are not parsed by bdrv_open() (like caching) cannot be specified for these BB-less BDS trees yet. A future patch will remove this limitation. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-09-04qemu-iotests: disable default qemu devices for cross-platform compatibilityBo Tu
This patch fixes an io test suite issue that was introduced with the commit c88930a6866e74953e931ae749781e98e486e5c8 'qemu-char: Permit only a single "stdio" character device'. The option supresses the creation of default devices such as the floopy and cdrom. Output files for test case 067, 071, 081 and 087 need to be updated to accommodate this change. Use virtio-blk instead of virtio-blk-pci as the device driver for test case 067. For virtio-blk-pci is the same with virtio-blk as device driver but other platform such as s390 may not recognize the virtio-blk-pci. The default devices differ across machines. As the qemu output often contains these devices (or events for them, like opening a CD tray on reset), the reference output currently is rather machine-specific. All existing qemu tests explicitly configure the devices they're working with, so just pass -nodefaults to qemu by default to disable the default devices. Update the reference outputs accordingly. Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Michael Mueller <mimu@linux.vnet.ibm.com> Reviewed-by: Sascha Silbe <silbe@linux.vnet.ibm.com> Signed-off-by: Xiao Guang Chen <chenxg@linux.vnet.ibm.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-03-16block: Deprecate QCOW/QCOW2 encryptionMarkus Armbruster
We've steered users away from QCOW/QCOW2 encryption for a while, because it's a flawed design (commit 136cd19 Describe flaws in qcow/qcow2 encryption in the docs). In addition to flawed crypto, we have comically bad usability, and plain old bugs. Let me show you. = Example images = I'm going to use a raw image as backing file, and two QCOW2 images, one encrypted, and one not: $ qemu-img create -f raw backing.img 4m Formatting 'backing.img', fmt=raw size=4194304 $ qemu-img create -f qcow2 -o encryption,backing_file=backing.img,backing_fmt=raw geheim.qcow2 4m Formatting 'geheim.qcow2', fmt=qcow2 size=4194304 backing_file='backing.img' backing_fmt='raw' encryption=on cluster_size=65536 lazy_refcounts=off $ qemu-img create -f qcow2 -o backing_file=backing.img,backing_fmt=raw normal.qcow2 4m Formatting 'normal.qcow2', fmt=qcow2 size=4194304 backing_file='backing.img' backing_fmt='raw' encryption=off cluster_size=65536 lazy_refcounts=off = Usability issues = == Confusing startup == When no image is encrypted, and you don't give -S, QEMU starts the guest immediately: $ qemu-system-x86_64 -nodefaults -display none -monitor stdio normal.qcow2 QEMU 2.2.50 monitor - type 'help' for more information (qemu) info status VM status: running But as soon as there's an encrypted image in play, the guest is *not* started, with no notification whatsoever: $ qemu-system-x86_64 -nodefaults -display none -monitor stdio geheim.qcow2 QEMU 2.2.50 monitor - type 'help' for more information (qemu) info status VM status: paused (prelaunch) If the user figured out that he needs to type "cont" to enter his keys, the confusion enters the next level: "cont" asks for at most *one* key. If more are needed, it then silently does nothing. The user has to type "cont" once per encrypted image: $ qemu-system-x86_64 -nodefaults -display none -monitor stdio -drive if=none,file=geheim.qcow2 -drive if=none,file=geheim.qcow2 QEMU 2.2.50 monitor - type 'help' for more information (qemu) info status VM status: paused (prelaunch) (qemu) c none0 (geheim.qcow2) is encrypted. Password: ****** (qemu) info status VM status: paused (prelaunch) (qemu) c none1 (geheim.qcow2) is encrypted. Password: ****** (qemu) info status VM status: running == Incorrect passwords not caught == All existing encryption schemes give you the GIGO treatment: garbage password in, garbage data out. Guests usually refuse to mount garbage, but other usage is prone to data loss. == Need to stop the guest to add an encrypted image == $ qemu-system-x86_64 -nodefaults -display none -monitor stdio QEMU 2.2.50 monitor - type 'help' for more information (qemu) info status VM status: running (qemu) drive_add "" if=none,file=geheim.qcow2 Guest must be stopped for opening of encrypted image (qemu) stop (qemu) drive_add "" if=none,file=geheim.qcow2 OK Commit c3adb58 added this restriction. Before, we could expose images lacking an encryption key to guests, with potentially catastrophic results. See also "Use without key is not always caught". = Bugs = == Use without key is not always caught == Encrypted images can be in an intermediate state "opened, but no key". The weird startup behavior and the need to stop the guest are there to ensure the guest isn't exposed to that state. But other things still are! * drive_backup $ qemu-system-x86_64 -nodefaults -display none -monitor stdio geheim.qcow2 QEMU 2.2.50 monitor - type 'help' for more information (qemu) drive_backup -f ide0-hd0 out.img raw Formatting 'out.img', fmt=raw size=4194304 I guess this writes encrypted data to raw image out.img. Good luck with figuring out how to decrypt that again. * commit $ qemu-system-x86_64 -nodefaults -display none -monitor stdio geheim.qcow2 QEMU 2.2.50 monitor - type 'help' for more information (qemu) commit ide0-hd0 I guess this writes encrypted data into the unencrypted raw backing image, effectively destroying it. == QMP device_add of usb-storage fails when it shouldn't == When the image is encrypted, device_add creates the device, defers actually attaching it to when the key becomes available, then fails. This is wrong. device_add must either create the device and succeed, or do nothing and fail. $ qemu-system-x86_64 -nodefaults -display none -usb -qmp stdio -drive if=none,id=foo,file=geheim.qcow2 {"QMP": {"version": {"qemu": {"micro": 50, "minor": 2, "major": 2}, "package": ""}, "capabilities": []}} { "execute": "qmp_capabilities" } {"return": {}} { "execute": "device_add", "arguments": { "driver": "usb-storage", "id": "bar", "drive": "foo" } } {"error": {"class": "DeviceEncrypted", "desc": "'foo' (geheim.qcow2) is encrypted"}} {"execute":"device_del","arguments": { "id": "bar" } } {"timestamp": {"seconds": 1426003440, "microseconds": 237181}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/bar/bar.0/legacy[0]"}} {"timestamp": {"seconds": 1426003440, "microseconds": 238231}, "event": "DEVICE_DELETED", "data": {"device": "bar", "path": "/machine/peripheral/bar"}} {"return": {}} This stuff is worse than useless, it's a trap for users. If people become sufficiently interested in encrypted images to contribute a cryptographically sane implementation for QCOW2 (or whatever other format), then rewriting the necessary support around it from scratch will likely be easier and yield better results than fixing up the existing mess. Let's deprecate the mess now, drop it after a grace period, and move on. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-16blockdev: Use blk_new_open() in blockdev_init()Max Reitz
Due to different error propagation, this breaks tests 051 and 087; fix their output. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1423162705-32065-6-git-send-email-mreitz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2015-01-13iotests: Filter out "I/O thread spun..." warningMax Reitz
Filter out the "main loop: WARNING: I/O thread spun for..." warning from qemu output (it hardly matters for code specifically testing I/O). Furthermore, use _filter_qemu in all the custom functions which run qemu. Signed-off-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-12-12qemu-iotests: Remove traling whitespaces in *.outFam Zheng
This is simply: $ cd tests/qemu-iotests; sed -i -e 's/ *$//' *.out Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-id: 1418110684-19528-2-git-send-email-famz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-09-29Merge remote-tracking branch 'remotes/qmp-unstable/queue/qmp' into stagingPeter Maydell
* remotes/qmp-unstable/queue/qmp: Add HMP command "info memory-devices" qemu-socket: Eliminate silly QERR_ macros qemu-socket: Polish errors for connect() and listen() failure qemu-iotests: Test missing "driver" key for blockdev-add tests: add QMP input visitor test for unions with no discriminator qapi: dealloc visitor, implement visit_start_union qapi: add visit_start_union and visit_end_union virtio-balloon: fix integer overflow in memory stats feature monitor: Reset HMP mon->rs in CHR_EVENT_OPEN Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2014-09-26qemu-iotests: Test missing "driver" key for blockdev-addFam Zheng
Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
2014-09-25block: Improve message for device name clashing with node nameMarkus Armbruster
Suggested-by: Benoit Canet <benoit.canet@nodalink.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: BenoƮt Canet <benoit.canet@nodalink.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-04-22qemu-iotests: Check common namespace for id and node-nameKevin Wolf
A name that is taken by an ID can't be taken by a node-name at the same time. Check that conflicts are correctly detected. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com>
2014-04-22block: Catch duplicate IDs in bdrv_new()Kevin Wolf
Since commit f298d071, block devices added with blockdev-add don't have a QemuOpts around in dinfo->opts. Consequently, we can't rely any more on QemuOpts catching duplicate IDs for block devices. This patch adds a new check for duplicate IDs to bdrv_new(), and moves the existing check that the ID isn't already taken for a node-name there as well. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-03-14blockdev: Refuse to open encrypted image unless pausedMarkus Armbruster
Opening an encrypted image takes an additional step: setting the key. Between open and the key set, the image must not be used. We have some protection against accidental use in place: you can't unpause a guest while we're missing keys. You can, however, hot-plug block devices lacking keys into a running guest just fine, or insert media lacking keys. In the latter case, notifying the guest of the insert is delayed until the key is set, which may suffice to protect at least some guests in common usage. This patch makes the protection apply in more cases, in a rather heavy-handed way: it doesn't let you open encrypted images unless we're in a paused state. It doesn't extend the protection to users other than the guest (block jobs?). Use of runstate_check() from block.c is disgusting. Best I can do right now. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-03-06qemu-iotests: Test a few blockdev-add error casesKevin Wolf
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Benoit Canet <benoit@irqsave.net>