From: Stefan Hajnoczi <stefanha@gmail.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: cornelia.huck@de.ibm.com, dahi@linux.vnet.ibm.com,
Ekaterina Tumanova <tumanova@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: Wed, 17 Sep 2014 14:56:43 +0100 [thread overview]
Message-ID: <20140917135643.GD25707@stefanha-thinkpad.redhat.com> (raw)
In-Reply-To: <540873F9.3010200@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3204 bytes --]
On Thu, Sep 04, 2014 at 04:15:21PM +0200, Christian Borntraeger wrote:
> On 03/09/14 17:46, Stefan Hajnoczi wrote:
> > On Tue, Jul 29, 2014 at 02:27:19PM +0200, Ekaterina Tumanova wrote:
> > 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?
Detection is only useful when installing a new guest from scratch.
> > 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?
No, QEMU already detects alignment requirements and uses bounce buffers.
So the guest can run under the illusion that 512 byte requests are okay
even on a 4 KB disk.
Please see block.c:bdrv_co_do_preadv()
This means existing guests that were installed on a 512 byte disk keep
running when you move them onto a 4 KB sector host block device.
If you want to pass the 4 KB requirement through, then set it explicitly
in the guest configuration.
> > 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.
This is not architecture-specific. If the current policy doesn't work
on s390 then the policy needs to be extended for all architectures.
My point is that QEMU cannot pass values from the host through to the
guest automatically since it changes what hardware configuration the
guest sees. Whether the guest is running (live migration) or across
boot (moving disk image to another machine) doesn't really matter, the
point is that the guest hardware configuration should be constant to
avoid upsetting guests.
For these reasons, I think that I/O alignment constraints should be
explicitly configured at the QEMU level.
Stefan
[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2014-09-17 13:57 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
2014-09-17 13:56 ` Stefan Hajnoczi [this message]
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=20140917135643.GD25707@stefanha-thinkpad.redhat.com \
--to=stefanha@gmail.com \
--cc=borntraeger@de.ibm.com \
--cc=cornelia.huck@de.ibm.com \
--cc=dahi@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--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).