Re: [libvirt] [Qemu-devel] [PULL 25/26] block: Remove deprecated -drive option serial

Am 22.06.2018 um 15:36 hat Christian Borntraeger geschrieben: > > > On 06/22/2018 02:55 PM, Kevin Wolf wrote: > > Am 22.06.2018 um 13:38 hat Christian Borntraeger geschrieben: > >> > >> On 06/15/2018 04:21 PM, Kevin Wolf wrote: > >>> The -drive option serial was deprecated in QEMU 2.10. It's time to > >>> remove it. > >>> > >>> Tests need to be updated to set the serial number with -global instead > >>> of using the -drive option. > >> > >> libvirt 4.5 still creates those (at least on s390x) > >> > >> <disk type='file' device='disk'> > >> <driver name='qemu' type='qcow2' cache='none' io='native' iothread='1'/> > >> <source file='/var/lib/libvirt/qemu/image.zhyp137'/> > >> <target dev='hda' bus='virtio'/> > >> <serial>skel</serial> > >> <boot order='1'/> > >> <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0000'/> > >> </disk> > >> > >> > >> -> > >> [...] > >> -drive file=/var/lib/libvirt/qemu/image.zhyp137,format=qcow2,if=none,id=drive-virtio-disk0,serial=skel,cache=none,aio=native -device virtio-blk-ccw,iothread=iothread1,scsi=off,devno=fe.0.0000,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on > >> [...] > >> > >> 2018-06-22T11:25:20.946024Z qemu-system-s390x: -drive file=/var/lib/libvirt/qemu/image.zhyp137,format=qcow2,if=none,id=drive-virtio-disk0,serial=skel,cache=none,aio=native: Block format 'qcow2' does not support the option 'serial' > >> 2018-06-22 11:25:21.098+0000: shutting down, reason=failed > >> > >> So it seems that this breaks s390x. > > To me it seems that this is also broken on x86. > > > > Thanks for bringing this up. libvirt should fix this before QEMU 3.0 is > > released. > > I think this is definitely too short notice. We should not break existing > setups just by insisting that users have to update libvirt when they update > QEMU. Yes, this might be our policy, but doing so "just because we can" > is certainly a very bad attitude. I see no fundamental technical reason why > we should not revert this change. This was in fact one release longer than our deprecation policy says. Are we serious about the deprecation policy or aren't we? I might consider reverting a change if it turned out that this requires some massive work in libvirt. But I think this one should be rather easy to fix in libvirt until 3.0 is released.