qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 4/4] blocksize: add blkconf_blocksize call to al


From: Stefan Hajnoczi
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
User-agent: Mutt/1.5.23 (2014-03-12)

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: pgpf7NeVIgLDL.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]