From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35246) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUFj9-00067Y-LB for qemu-devel@nongnu.org; Wed, 17 Sep 2014 09:57:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUFj0-0006iX-DY for qemu-devel@nongnu.org; Wed, 17 Sep 2014 09:56:59 -0400 Received: from mail-we0-x22e.google.com ([2a00:1450:400c:c03::22e]:33775) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUFj0-0006i1-3G for qemu-devel@nongnu.org; Wed, 17 Sep 2014 09:56:50 -0400 Received: by mail-we0-f174.google.com with SMTP id x48so607542wes.5 for ; Wed, 17 Sep 2014 06:56:46 -0700 (PDT) Date: Wed, 17 Sep 2014 14:56:43 +0100 From: Stefan Hajnoczi Message-ID: <20140917135643.GD25707@stefanha-thinkpad.redhat.com> References: <1406636839-11946-1-git-send-email-tumanova@linux.vnet.ibm.com> <1406636839-11946-5-git-send-email-tumanova@linux.vnet.ibm.com> <20140903154636.GB30664@stefanha-thinkpad.redhat.com> <540873F9.3010200@de.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SFyWQ0h3ruR435lw" Content-Disposition: inline In-Reply-To: <540873F9.3010200@de.ibm.com> Subject: Re: [Qemu-devel] [PATCH 4/4] blocksize: add blkconf_blocksize call to all block devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christian Borntraeger Cc: cornelia.huck@de.ibm.com, dahi@linux.vnet.ibm.com, Ekaterina Tumanova , Public KVM Mailing List --SFyWQ0h3ruR435lw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > Would it be more acceptable if this auto detection is only running on ini= t, > 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. >=20 > I think the main problem that this patch tries to address is, is not migr= ation.=20 > 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 imag= e file) and > the disk happens to be a 4Kn disk. >=20 > Question is: Do we want all users to specify the block size of the underl= ying disk, > just because its a 4Kn-type disk? >=20 > Or in other words: > shall we force everybody to change > qemu-system-x86_64 -hda /dev/sdc >=20 > into=20 > qemu-system-x86_64 -drive file=3D/dev/sdc,if=3Dnone,id=3Dmydisk -device i= de-drive,bus=3Dide.0,drive=3Dmydisk,physical_block_size=3D4096 > for a 4Kn device? >=20 > Or for the libvirt case, we need > >=20 > Or is your suggestion to let libvirt detect the block size for host devic= es? 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. > >=20 > > 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. >=20 > I am totally with you, that we should make this patch in a way to not bre= ak 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 --SFyWQ0h3ruR435lw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUGZMbAAoJEJykq7OBq3PIQaYIALCwXoZwA4WWWu1Wg2V5Tez0 s0NG4D7Cns9wRLUa7ehPU7DwtannWNatJuZjlD0nNS8o6E5Y74n7ABCUwF7X309n u46MnNhK4ACaVUaltiGoFki/nLxMNo+9QdBaAN73O3qBei5u2SMm9h8XkCW5u/4c 6Mrt3K6qU6wvosyuilGCBHSgMVFYCYTRqeKZjC+jZfdNRB8Rf89CMeYqPEWhnngW sPxS2pQBw5s207MyfAgqdn6tO5KItqJaHxUHp44lF1T4jIZGqMYl2XaOhm8JlDoV yLrO5VdvSnXMiJzjjsecKPRm7OQSWrDcr3Uot3cQ8xbe9D1F7ZL3OQ70NfmjETk= =usy3 -----END PGP SIGNATURE----- --SFyWQ0h3ruR435lw--