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. 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
