On Thu, Jan 31, 2019 at 01:56:57PM +0100, Peter Krempa wrote: > On Thu, Jan 31, 2019 at 12:31:58 +0000, Daniel Berrange wrote: > > On Thu, Jan 31, 2019 at 01:26:24PM +0100, Peter Krempa wrote: > > > On Tue, Jan 29, 2019 at 16:06:35 +0000, Daniel Berrange wrote: > > > > On Mon, Jan 28, 2019 at 05:19:00PM +0100, Peter Krempa wrote: > > > > > QEMU accidentally exposed the id of -drive (or same value as disk > > > > > serial, if provided) in one of the identifiers visible from the guest. > > > > > > > > > > To avoid regression in case when -blockdev will be used we need to > > > > > always specify it ourselves. > > > > > > > > > > Signed-off-by: Peter Krempa <pkrempa@xxxxxxxxxx> > > > > > --- > > > > > src/qemu/qemu_command.c | 22 +++++++++++++++++++ > > > > > .../controller-virtio-scsi.x86_64-latest.args | 20 ++++++++--------- > > > > > .../disk-cache.x86_64-latest.args | 4 ++-- > > > > > .../disk-scsi-device-auto.x86_64-latest.args | 3 ++- > > > > > .../disk-scsi.x86_64-latest.args | 16 ++++++++------ > > > > > .../disk-shared.x86_64-latest.args | 5 +++-- > > > > > ...threads-virtio-scsi-pci.x86_64-latest.args | 4 ++-- > > > > > 7 files changed, 50 insertions(+), 24 deletions(-) > > > > > > [...] > > > > > > > I rather wish there was a way we could avoid exposing the alias ID to every > > > > guest forever more. > > > > > > > > QEMU could achieve that with machine type versioning, so that it only exposes > > > > the drive ID to guests with legacy machine types for sake of backport. We need > > > > to explicitly set this though, as with -blockdev QEMU can't do the right thing > > > > for legacy machine types as it lacks tie drive ID entirely. Once we set it, > > > > we enable it for non-legacy machine types too :-( Annoyingly I don't see a > > > > way out of this mess such that libvirt only enables the back compat for > > > > existing guests. > > > > > > Do you mean that for any new machine type we should not put the -drive > > > ID as the 'device_id' property? AFAIK qemu should now handle that > > > correctly by not creating any ID. > > > > > > In that case we could tie -blockdev to the new machine type only and > > > thus will not need to add any code to format the backward compatibility > > > stuff. > > > > The tricky thing is how to tie the -blockdev to the new machine type. > > Libvirt generally aims to treat the version part of the machine type > > as an opaque string, because it can be arbitrarily changed by distros, > > so there's no reliable way to determine "newest" version for a machine > > type. At best we know that one of them is the default and so the latest, > > but we don't know anything about ordering of others. > > Well, if we don't want to look at the machine type I don't see much other > options than to just always add the property forever. The only thing I can imagine working is if QEMU extends the 'query-machines' QMP data to add a flag "use-blockdev" to indicate whether it is ok to use blockdev or not. This feels like too much of a special case hack to warrant exposing in QMP though. So I think we'll just have to live with the gross property forever Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
