From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Stefan Hajnoczi <stefanha@gmail.com>,
Ekaterina Tumanova <tumanova@linux.vnet.ibm.com>
Cc: cornelia.huck@de.ibm.com, dahi@linux.vnet.ibm.com,
Public KVM Mailing List <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH 4/4] blocksize: add blkconf_blocksize call to all block devices
Date: Thu, 04 Sep 2014 16:15:21 +0200 [thread overview]
Message-ID: <540873F9.3010200@de.ibm.com> (raw)
In-Reply-To: <20140903154636.GB30664@stefanha-thinkpad.redhat.com>
On 03/09/14 17:46, Stefan Hajnoczi wrote:
> On Tue, Jul 29, 2014 at 02:27:19PM +0200, Ekaterina Tumanova wrote:
>> This patch add the blkconf_blocksize call to all
>> devices, which use DEFINE_BLOCK_PROPERTIES.
>> If the underlying driver function fails, blkconf_blocksizes
>> will set blocksizes to default (512) value.
>>
>> Signed-off-by: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com>
>> Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
>> Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com>
>> ---
>> hw/block/nvme.c | 1 +
>> hw/block/virtio-blk.c | 1 +
>> hw/ide/qdev.c | 1 +
>> hw/scsi/scsi-disk.c | 1 +
>> hw/usb/dev-storage.c | 1 +
>> include/hw/block/block.h | 4 ++--
>> 6 files changed, 7 insertions(+), 2 deletions(-)
>
> Wasn't this NACKed before on the grounds that it is likely to upset the
Not yet ;-) (just other other comments)
> guest after live migration? QEMU doesn't automatically query the
> storage because these parameters must be preserved across migration.
Would it be more acceptable if this auto detection is only running on init,
but on migration the target will use the block size of the source?
>
> The knowledge of these fields belongs in the management tool that
> orchestrates migration, not QEMU.
I think the main problem that this patch tries to address is, is not migration.
It tries to make the whole guest work an pass-through dasd. It guess that this problem
did not happen on x86 yet as most disks are 512 and most file system will cope with
sector size changes.
Maybe this will change as soon as you run a guest on a real disk (no image file) and
the disk happens to be a 4Kn disk.
Question is: Do we want all users to specify the block size of the underlying disk,
just because its a 4Kn-type disk?
Or in other words:
shall we force everybody to change
qemu-system-x86_64 -hda /dev/sdc
into
qemu-system-x86_64 -drive file=/dev/sdc,if=none,id=mydisk -device ide-drive,bus=ide.0,drive=mydisk,physical_block_size=4096
for a 4Kn device?
Or for the libvirt case, we need
<blockio logical_block_size='4096' physical_block_size='4096'/>
Or is your suggestion to let libvirt detect the block size for host devices?
> If you want specific parameters, please put them in your guest
> configuration. QEMU and libvirt support that.
>
> I'm concerned that this patch serious is likely to break things and
> autodetection doesn't add much value since the management tool needs to
> be aware of this information anyway.
I am totally with you, that we should make this patch in a way to not break anything on other platforms.
Christian
next prev parent reply other threads:[~2014-09-04 14:15 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-29 12:27 [Qemu-devel] [PATCH 0/4] Geometry and blocksize support for backing devices Ekaterina Tumanova
2014-07-29 12:27 ` [Qemu-devel] [PATCH 1/4] hd-geometry.c: Integrate HDIO_GETGEO in guessing for target-s390x Ekaterina Tumanova
2014-08-20 8:19 ` Paolo Bonzini
2014-08-20 9:35 ` Christian Borntraeger
2014-08-20 13:10 ` Paolo Bonzini
2014-08-25 8:21 ` Christian Borntraeger
2014-07-29 12:27 ` [Qemu-devel] [PATCH 2/4] blocksize: support auto-sensing of blocksizes Ekaterina Tumanova
2014-09-03 15:37 ` Stefan Hajnoczi
2014-07-29 12:27 ` [Qemu-devel] [PATCH 3/4] blocksize: Add driver method to get the blocksizes Ekaterina Tumanova
2014-07-29 12:27 ` [Qemu-devel] [PATCH 4/4] blocksize: add blkconf_blocksize call to all block devices Ekaterina Tumanova
2014-09-03 15:46 ` Stefan Hajnoczi
2014-09-04 10:28 ` Ekaterina Tumanova
2014-09-17 14:00 ` Stefan Hajnoczi
2014-09-04 14:15 ` Christian Borntraeger [this message]
2014-09-17 13:56 ` Stefan Hajnoczi
2014-07-29 12:37 ` [Qemu-devel] [PATCH 0/4] Geometry and blocksize support for backing devices Christian Borntraeger
2014-11-06 15:58 ` [Qemu-devel] " Christian Borntraeger
2014-11-06 17:24 ` Paolo Bonzini
2014-11-06 19:05 ` Christian Borntraeger
2014-11-07 9:17 ` Markus Armbruster
2014-11-07 9:48 ` Christian Borntraeger
2014-11-07 15:58 ` Markus Armbruster
2014-11-07 13:39 ` Ekaterina Tumanova
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=540873F9.3010200@de.ibm.com \
--to=borntraeger@de.ibm.com \
--cc=cornelia.huck@de.ibm.com \
--cc=dahi@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=tumanova@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).