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
