Re: [Qemu-devel] [PATCH v5 0/5] Geometry and blocksize detection for backing devices.

[Christian Borntraeger <borntraeger@de.ibm.com>]

Am 02.01.2015 um 13:57 schrieb Stefan Hajnoczi:
> On Thu, Dec 18, 2014 at 04:59:50PM +0100, Christian Borntraeger wrote:
>> Are you ok with the patches? If yes, can you take care of these patches in the block tree?
> 
> This series looks close, I've left comments on the patches.

OK, so you would take care of the series in your tree if the next spin addresses your comments, right?
> 
> The series is fine for command-line QEMU users where probing makes the
> command-line more convenient, so we can merge it.  But the approach is
> fundamentally wrong for stacks where libvirt is in use.
> Libvirt is unaware of the guest geometry and block sizes that are probed
> in QEMU by this patch series.  This breaks non-shared storage migration
> and also means libvirt-based tools that manipulate drives on a guest may
> inadvertently change the guest-visible geometry and cause disk problems.
> 
> For example, what happens when you copy the disk image off a host DASD
> and onto NFS?  QEMU no longer probes the geometry and the disk geometry
> has changed.
> 
> The right place to tackle guest-visible geometry is in libvirt, not in
> QEMU, because it is guest state the needs to be captured in domain XML
> so that migration and tooling can preserve it when manipulating guests.
> 
> Stefan
> 

I agree that this is not perfect and has obvious holes, but  it works 
just fine with libvirt stacks that are typical on s390 (*). scsi disks
(emulated and real) are not affected and work just fine. DASD disks are
special anyway - please consider this as some kind of real HW pass-through
even when we use virtio-blk. We can assume that admins can provide
shared access between source and target. If you look at the real HW (LPAR
and z/VM) DASDs are always attached via fibre channel (FICON protocol)
(often with SAN switches) so shared access is quite common even over longer
distances.

And yes, using NFS or image file will break unless the user specifies the
geometry in libvirt. Setting these values is possible as of today in libvirts
XML. But what programmatic way should libvirt use to detect that information 
itself? On an image file libvirt doesnt know either. This would be somewhat
possible on an upper level like open stack and that upper level would then
need to talk with the DS8000 storage subsystems and the system z hardware but
even then it would fail when creating new DASD like images.  (This would boil
down to provide an interface like "create an image file that looks like as
DASD of type 3390/xx formatted with dasdfmt and the following parameters).


If we talk about cloud/openstack etc we do not have pass through devices anyway
and only image files. If somebody asks me, I would create all image files as 
SCSI images anyway, all the DASD stuff makes sense if you have DASD hardware 
(or if you really know what you are going to do).

What is your opinion on 
a) migrating disk properties like geometry
b) comparing the detected disk properties and reject migration if they
   dont match?
Both changes  should provide a safety net and could be added at a later
point in time.

I hope that clarifies some of the aspects and why I think that this patch series would be "good enough" for most cases. Makes sense?

Christian

PS: Proper DASD support might require a DASD emulation and/or passthrough
without virtio-blk. There are some very special operations (like low-level
format, raw-track access, reserve/release) which are pretty hard to 
virtualize with virtio-blk.

(*) Well, thats my guess,  as there are not many stacks on s390 yet in production 
as far as I know