[PATCH] qemu: Switch to virtio-scsi on ARM
From: Jim Fehlig <jfehlig@suse.com> Similar to x86, the default SCSI controller model for ARM is lsilogic. But unlike x86, the ARM virt machine type prefers virtio devices. Switch the default controller model for ARM from lsilogic to virtio-scsi. Signed-off-by: Jim Fehlig <jfehlig@suse.com> --- IMO, the lsilogic SCSI controller is a poor default for the ARM virt machine type. One could argue modern operating systems are more likely to contain a functional virtio-scsi driver than an LSI one. However, I do understand this change could break existing ARM VM configurations containing a SCSI controller without a model specification. One could also argue the pain inflicted is tolerable :-). The test churn is interesting. I haven't yet investigated if there's an underlying bug, or if it's a consequence of libvirt's processing of controllers. Much appreciated if anyone has an explanation handy :-). src/qemu/qemu_domain.c | 3 ++- ...ault-models.aarch64-latest.abi-update.args | 13 +++++------ ...fault-models.aarch64-latest.abi-update.xml | 22 ++++++++----------- ...64-virt-default-models.aarch64-latest.args | 13 +++++------ ...h64-virt-default-models.aarch64-latest.xml | 22 ++++++++----------- 5 files changed, 32 insertions(+), 41 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 0d2548d8d4..499db0ad78 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -4252,7 +4252,8 @@ qemuDomainGetSCSIControllerModel(const virDomainDef *def, if (qemuDomainIsPSeries(def)) return VIR_DOMAIN_CONTROLLER_MODEL_SCSI_IBMVSCSI; - if (ARCH_IS_S390(def->os.arch) || qemuDomainIsLoongArchVirt(def)) + if (ARCH_IS_ARM(def->os.arch) || ARCH_IS_S390(def->os.arch) || + qemuDomainIsLoongArchVirt(def)) return VIR_DOMAIN_CONTROLLER_MODEL_SCSI_VIRTIO_SCSI; if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_SCSI_LSI)) return VIR_DOMAIN_CONTROLLER_MODEL_SCSI_LSILOGIC; diff --git a/tests/qemuxmlconfdata/aarch64-virt-default-models.aarch64-latest.abi-update.args b/tests/qemuxmlconfdata/aarch64-virt-default-models.aarch64-latest.abi-update.args index 96fb251d80..ff86567c59 100644 --- a/tests/qemuxmlconfdata/aarch64-virt-default-models.aarch64-latest.abi-update.args +++ b/tests/qemuxmlconfdata/aarch64-virt-default-models.aarch64-latest.abi-update.args @@ -29,20 +29,19 @@ XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain--1-guest/.config \ -device '{"driver":"pcie-root-port","port":8,"chassis":1,"id":"pci.1","bus":"pcie.0","multifunction":true,"addr":"0x1"}' \ -device '{"driver":"pcie-root-port","port":9,"chassis":2,"id":"pci.2","bus":"pcie.0","addr":"0x1.0x1"}' \ -device '{"driver":"pcie-root-port","port":10,"chassis":3,"id":"pci.3","bus":"pcie.0","addr":"0x1.0x2"}' \ --device '{"driver":"pcie-pci-bridge","id":"pci.4","bus":"pci.1","addr":"0x0"}' \ --device '{"driver":"pcie-root-port","port":11,"chassis":5,"id":"pci.5","bus":"pcie.0","addr":"0x1.0x3"}' \ --device '{"driver":"pcie-root-port","port":12,"chassis":6,"id":"pci.6","bus":"pcie.0","addr":"0x1.0x4"}' \ --device '{"driver":"qemu-xhci","id":"usb","bus":"pci.3","addr":"0x0"}' \ --device '{"driver":"lsi","id":"scsi0","bus":"pci.4","addr":"0x1"}' \ +-device '{"driver":"pcie-root-port","port":11,"chassis":4,"id":"pci.4","bus":"pcie.0","addr":"0x1.0x3"}' \ +-device '{"driver":"pcie-root-port","port":12,"chassis":5,"id":"pci.5","bus":"pcie.0","addr":"0x1.0x4"}' \ +-device '{"driver":"qemu-xhci","id":"usb","bus":"pci.2","addr":"0x0"}' \ +-device '{"driver":"virtio-scsi-pci","id":"scsi0","bus":"pci.3","addr":"0x0"}' \ -netdev '{"type":"user","id":"hostnet0"}' \ --device '{"driver":"virtio-net-pci","netdev":"hostnet0","id":"net0","mac":"52:54:00:09:a4:37","bus":"pci.2","addr":"0x0"}' \ +-device '{"driver":"virtio-net-pci","netdev":"hostnet0","id":"net0","mac":"52:54:00:09:a4:37","bus":"pci.1","addr":"0x0"}' \ -chardev pty,id=charserial0 \ -serial chardev:charserial0 \ -chardev socket,id=chrtpm,path=/dev/test \ -tpmdev emulator,id=tpm-tpm0,chardev=chrtpm \ -device '{"driver":"tpm-tis-device","tpmdev":"tpm-tpm0","id":"tpm0"}' \ -audiodev '{"id":"audio1","driver":"none"}' \ --device '{"driver":"virtio-gpu-pci","id":"video0","max_outputs":1,"bus":"pci.5","addr":"0x0"}' \ +-device '{"driver":"virtio-gpu-pci","id":"video0","max_outputs":1,"bus":"pci.4","addr":"0x0"}' \ -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ -device '{"driver":"pvpanic-pci","bus":"pcie.0","addr":"0x2"}' \ -msg timestamp=on diff --git a/tests/qemuxmlconfdata/aarch64-virt-default-models.aarch64-latest.abi-update.xml b/tests/qemuxmlconfdata/aarch64-virt-default-models.aarch64-latest.abi-update.xml index f27e7e1522..5abf55cf36 100644 --- a/tests/qemuxmlconfdata/aarch64-virt-default-models.aarch64-latest.abi-update.xml +++ b/tests/qemuxmlconfdata/aarch64-virt-default-models.aarch64-latest.abi-update.xml @@ -21,11 +21,11 @@ <devices> <emulator>/usr/bin/qemu-system-aarch64</emulator> <controller type='usb' index='0' model='qemu-xhci'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> + </controller> + <controller type='scsi' index='0' model='virtio-scsi'> <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </controller> - <controller type='scsi' index='0' model='lsilogic'> - <address type='pci' domain='0x0000' bus='0x04' slot='0x01' function='0x0'/> - </controller> <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='pcie-root-port'> <model name='pcie-root-port'/> @@ -42,24 +42,20 @@ <target chassis='3' port='0xa'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> - <controller type='pci' index='4' model='pcie-to-pci-bridge'> - <model name='pcie-pci-bridge'/> - <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> - </controller> - <controller type='pci' index='5' model='pcie-root-port'> + <controller type='pci' index='4' model='pcie-root-port'> <model name='pcie-root-port'/> - <target chassis='5' port='0xb'/> + <target chassis='4' port='0xb'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x3'/> </controller> - <controller type='pci' index='6' model='pcie-root-port'> + <controller type='pci' index='5' model='pcie-root-port'> <model name='pcie-root-port'/> - <target chassis='6' port='0xc'/> + <target chassis='5' port='0xc'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x4'/> </controller> <interface type='user'> <mac address='52:54:00:09:a4:37'/> <model type='virtio'/> - <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> <serial type='pty'> <target type='system-serial' port='0'> @@ -75,7 +71,7 @@ <audio id='1' type='none'/> <video> <model type='virtio' heads='1' primary='yes'/> - <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> + <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </video> <memballoon model='none'/> <panic model='pvpanic'> diff --git a/tests/qemuxmlconfdata/aarch64-virt-default-models.aarch64-latest.args b/tests/qemuxmlconfdata/aarch64-virt-default-models.aarch64-latest.args index 96fb251d80..ff86567c59 100644 --- a/tests/qemuxmlconfdata/aarch64-virt-default-models.aarch64-latest.args +++ b/tests/qemuxmlconfdata/aarch64-virt-default-models.aarch64-latest.args @@ -29,20 +29,19 @@ XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain--1-guest/.config \ -device '{"driver":"pcie-root-port","port":8,"chassis":1,"id":"pci.1","bus":"pcie.0","multifunction":true,"addr":"0x1"}' \ -device '{"driver":"pcie-root-port","port":9,"chassis":2,"id":"pci.2","bus":"pcie.0","addr":"0x1.0x1"}' \ -device '{"driver":"pcie-root-port","port":10,"chassis":3,"id":"pci.3","bus":"pcie.0","addr":"0x1.0x2"}' \ --device '{"driver":"pcie-pci-bridge","id":"pci.4","bus":"pci.1","addr":"0x0"}' \ --device '{"driver":"pcie-root-port","port":11,"chassis":5,"id":"pci.5","bus":"pcie.0","addr":"0x1.0x3"}' \ --device '{"driver":"pcie-root-port","port":12,"chassis":6,"id":"pci.6","bus":"pcie.0","addr":"0x1.0x4"}' \ --device '{"driver":"qemu-xhci","id":"usb","bus":"pci.3","addr":"0x0"}' \ --device '{"driver":"lsi","id":"scsi0","bus":"pci.4","addr":"0x1"}' \ +-device '{"driver":"pcie-root-port","port":11,"chassis":4,"id":"pci.4","bus":"pcie.0","addr":"0x1.0x3"}' \ +-device '{"driver":"pcie-root-port","port":12,"chassis":5,"id":"pci.5","bus":"pcie.0","addr":"0x1.0x4"}' \ +-device '{"driver":"qemu-xhci","id":"usb","bus":"pci.2","addr":"0x0"}' \ +-device '{"driver":"virtio-scsi-pci","id":"scsi0","bus":"pci.3","addr":"0x0"}' \ -netdev '{"type":"user","id":"hostnet0"}' \ --device '{"driver":"virtio-net-pci","netdev":"hostnet0","id":"net0","mac":"52:54:00:09:a4:37","bus":"pci.2","addr":"0x0"}' \ +-device '{"driver":"virtio-net-pci","netdev":"hostnet0","id":"net0","mac":"52:54:00:09:a4:37","bus":"pci.1","addr":"0x0"}' \ -chardev pty,id=charserial0 \ -serial chardev:charserial0 \ -chardev socket,id=chrtpm,path=/dev/test \ -tpmdev emulator,id=tpm-tpm0,chardev=chrtpm \ -device '{"driver":"tpm-tis-device","tpmdev":"tpm-tpm0","id":"tpm0"}' \ -audiodev '{"id":"audio1","driver":"none"}' \ --device '{"driver":"virtio-gpu-pci","id":"video0","max_outputs":1,"bus":"pci.5","addr":"0x0"}' \ +-device '{"driver":"virtio-gpu-pci","id":"video0","max_outputs":1,"bus":"pci.4","addr":"0x0"}' \ -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ -device '{"driver":"pvpanic-pci","bus":"pcie.0","addr":"0x2"}' \ -msg timestamp=on diff --git a/tests/qemuxmlconfdata/aarch64-virt-default-models.aarch64-latest.xml b/tests/qemuxmlconfdata/aarch64-virt-default-models.aarch64-latest.xml index f27e7e1522..5abf55cf36 100644 --- a/tests/qemuxmlconfdata/aarch64-virt-default-models.aarch64-latest.xml +++ b/tests/qemuxmlconfdata/aarch64-virt-default-models.aarch64-latest.xml @@ -21,11 +21,11 @@ <devices> <emulator>/usr/bin/qemu-system-aarch64</emulator> <controller type='usb' index='0' model='qemu-xhci'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> + </controller> + <controller type='scsi' index='0' model='virtio-scsi'> <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </controller> - <controller type='scsi' index='0' model='lsilogic'> - <address type='pci' domain='0x0000' bus='0x04' slot='0x01' function='0x0'/> - </controller> <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='pcie-root-port'> <model name='pcie-root-port'/> @@ -42,24 +42,20 @@ <target chassis='3' port='0xa'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> - <controller type='pci' index='4' model='pcie-to-pci-bridge'> - <model name='pcie-pci-bridge'/> - <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> - </controller> - <controller type='pci' index='5' model='pcie-root-port'> + <controller type='pci' index='4' model='pcie-root-port'> <model name='pcie-root-port'/> - <target chassis='5' port='0xb'/> + <target chassis='4' port='0xb'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x3'/> </controller> - <controller type='pci' index='6' model='pcie-root-port'> + <controller type='pci' index='5' model='pcie-root-port'> <model name='pcie-root-port'/> - <target chassis='6' port='0xc'/> + <target chassis='5' port='0xc'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x4'/> </controller> <interface type='user'> <mac address='52:54:00:09:a4:37'/> <model type='virtio'/> - <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> <serial type='pty'> <target type='system-serial' port='0'> @@ -75,7 +71,7 @@ <audio id='1' type='none'/> <video> <model type='virtio' heads='1' primary='yes'/> - <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> + <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </video> <memballoon model='none'/> <panic model='pvpanic'> -- 2.43.0
On Thu, Jun 26, 2025 at 03:29:58PM -0600, Jim Fehlig via Devel wrote:
Similar to x86, the default SCSI controller model for ARM is lsilogic. But unlike x86, the ARM virt machine type prefers virtio devices. Switch the default controller model for ARM from lsilogic to virtio-scsi.
Signed-off-by: Jim Fehlig <jfehlig@suse.com> ---
IMO, the lsilogic SCSI controller is a poor default for the ARM virt machine type. One could argue modern operating systems are more likely to contain a functional virtio-scsi driver than an LSI one.
Agreed. Note that virt-manager has been defaulting to virtio-scsi on all architectures for a fairly long time now[1].
However, I do understand this change could break existing ARM VM configurations containing a SCSI controller without a model specification. One could also argue the pain inflicted is tolerable :-).
I don't think this should necessarily be a concern. Unlike, say, USB controllers, where in some cases you could end up with no model recorded in the XML, for SCSI controllers we always either figure out a suitable model or fail defining the domain altogether. So changing the default here should have no impact on existing domains and simply improve things for newly-created ones. I had a similar change for RISC-V as part of a series I posted a while ago[2] and that I should probably pick back up. Extending that to Arm sounds good to me.
The test churn is interesting. I haven't yet investigated if there's an underlying bug, or if it's a consequence of libvirt's processing of controllers. Much appreciated if anyone has an explanation handy :-).
The diff looks good. Unlike virtio-scsi-pci, lsi is a traditional PCI device, so attaching it to the PCIe-native virt machine type requires using a pcie-pci-bridge controller. Once libvirt no longer needs to add that, PCI addresses will naturally shift around a bit.
+++ b/src/qemu/qemu_domain.c @@ -4252,7 +4252,8 @@ qemuDomainGetSCSIControllerModel(const virDomainDef *def,
if (qemuDomainIsPSeries(def)) return VIR_DOMAIN_CONTROLLER_MODEL_SCSI_IBMVSCSI; - if (ARCH_IS_S390(def->os.arch) || qemuDomainIsLoongArchVirt(def)) + if (ARCH_IS_ARM(def->os.arch) || ARCH_IS_S390(def->os.arch) || + qemuDomainIsLoongArchVirt(def)) return VIR_DOMAIN_CONTROLLER_MODEL_SCSI_VIRTIO_SCSI;
I would use qemuDomainIsARMVirt() instead of ARCH_IS_ARM() here. I don't have a strong motivation to offer, but generally I've been using the former because it's much easier to justify that some changes are valid when applied to the virt machine type specifically, rather than to any possible Arm machine type. With that changed Reviewed-by: Andrea Bolognani <abologna@redhat.com> but please wait a few days before pushing so that other developers have a chance to point out any potential issue with this change that I might not have considered. [1] https://github.com/virt-manager/virt-manager/commit/47753eab26b64a702db75def... [2] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/FZ6BT... -- Andrea Bolognani / Red Hat / Virtualization
On 7/2/25 10:11, Andrea Bolognani wrote:
On Thu, Jun 26, 2025 at 03:29:58PM -0600, Jim Fehlig via Devel wrote:
Similar to x86, the default SCSI controller model for ARM is lsilogic. But unlike x86, the ARM virt machine type prefers virtio devices. Switch the default controller model for ARM from lsilogic to virtio-scsi.
Signed-off-by: Jim Fehlig <jfehlig@suse.com> ---
IMO, the lsilogic SCSI controller is a poor default for the ARM virt machine type. One could argue modern operating systems are more likely to contain a functional virtio-scsi driver than an LSI one.
Agreed.
Note that virt-manager has been defaulting to virtio-scsi on all architectures for a fairly long time now[1].
However, I do understand this change could break existing ARM VM configurations containing a SCSI controller without a model specification. One could also argue the pain inflicted is tolerable :-).
I don't think this should necessarily be a concern.
Unlike, say, USB controllers, where in some cases you could end up with no model recorded in the XML, for SCSI controllers we always either figure out a suitable model or fail defining the domain altogether.
So changing the default here should have no impact on existing domains and simply improve things for newly-created ones.
I was thinking of transient domains with no explicit model defined. Prior to this change they would get lsilogic, afterwards virtio-scsi. In practice I doubt there are (m)any such domains in existence.
I had a similar change for RISC-V as part of a series I posted a while ago[2] and that I should probably pick back up. Extending that to Arm sounds good to me.
The test churn is interesting. I haven't yet investigated if there's an underlying bug, or if it's a consequence of libvirt's processing of controllers. Much appreciated if anyone has an explanation handy :-).
The diff looks good.
Unlike virtio-scsi-pci, lsi is a traditional PCI device, so attaching it to the PCIe-native virt machine type requires using a pcie-pci-bridge controller.
Once libvirt no longer needs to add that, PCI addresses will naturally shift around a bit.
Thanks for the explanation. I also refreshed my memory with https://libvirt.org/pci-hotplug.html.
+++ b/src/qemu/qemu_domain.c @@ -4252,7 +4252,8 @@ qemuDomainGetSCSIControllerModel(const virDomainDef *def,
if (qemuDomainIsPSeries(def)) return VIR_DOMAIN_CONTROLLER_MODEL_SCSI_IBMVSCSI; - if (ARCH_IS_S390(def->os.arch) || qemuDomainIsLoongArchVirt(def)) + if (ARCH_IS_ARM(def->os.arch) || ARCH_IS_S390(def->os.arch) || + qemuDomainIsLoongArchVirt(def)) return VIR_DOMAIN_CONTROLLER_MODEL_SCSI_VIRTIO_SCSI;
I would use qemuDomainIsARMVirt() instead of ARCH_IS_ARM() here.
I've squashed the below into my local branch diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 499db0ad78..dd9459ebc0 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -4252,7 +4252,7 @@ qemuDomainGetSCSIControllerModel(const virDomainDef *def, if (qemuDomainIsPSeries(def)) return VIR_DOMAIN_CONTROLLER_MODEL_SCSI_IBMVSCSI; - if (ARCH_IS_ARM(def->os.arch) || ARCH_IS_S390(def->os.arch) || + if (ARCH_IS_S390(def->os.arch) || qemuDomainIsARMVirt(def) || qemuDomainIsLoongArchVirt(def)) return VIR_DOMAIN_CONTROLLER_MODEL_SCSI_VIRTIO_SCSI; if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_SCSI_LSI))
I don't have a strong motivation to offer, but generally I've been using the former because it's much easier to justify that some changes are valid when applied to the virt machine type specifically, rather than to any possible Arm machine type.
With that changed
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
but please wait a few days before pushing so that other developers have a chance to point out any potential issue with this change that I might not have considered.
Thanks for the review. I'll push it next week if there are no objections. Regards, Jim
On Wed, Jul 02, 2025 at 02:01:07PM -0600, Jim Fehlig wrote:
On 7/2/25 10:11, Andrea Bolognani wrote:
On Thu, Jun 26, 2025 at 03:29:58PM -0600, Jim Fehlig via Devel wrote:
However, I do understand this change could break existing ARM VM configurations containing a SCSI controller without a model specification. One could also argue the pain inflicted is tolerable :-).
I don't think this should necessarily be a concern.
Unlike, say, USB controllers, where in some cases you could end up with no model recorded in the XML, for SCSI controllers we always either figure out a suitable model or fail defining the domain altogether.
So changing the default here should have no impact on existing domains and simply improve things for newly-created ones.
I was thinking of transient domains with no explicit model defined. Prior to this change they would get lsilogic, afterwards virtio-scsi. In practice I doubt there are (m)any such domains in existence.
I don't use transient domains so I might be missing something, but my understanding is that by definition they can't really expect ABI stability to the extent regular domains can since every creation event is independent from the previous ones from libvirt's perspective. We have a bunch of cases in which we do things differently for existing domains compared to newly-created ones, specifically in order to preserve ABI stability, and IIUC transient domains will always get the latter behavior. So I think we're still in the clear. -- Andrea Bolognani / Red Hat / Virtualization
On Thu, Jul 03, 2025 at 06:02:38AM -0400, Andrea Bolognani via Devel wrote:
On Wed, Jul 02, 2025 at 02:01:07PM -0600, Jim Fehlig wrote:
On 7/2/25 10:11, Andrea Bolognani wrote:
On Thu, Jun 26, 2025 at 03:29:58PM -0600, Jim Fehlig via Devel wrote:
However, I do understand this change could break existing ARM VM configurations containing a SCSI controller without a model specification. One could also argue the pain inflicted is tolerable :-).
I don't think this should necessarily be a concern.
Unlike, say, USB controllers, where in some cases you could end up with no model recorded in the XML, for SCSI controllers we always either figure out a suitable model or fail defining the domain altogether.
So changing the default here should have no impact on existing domains and simply improve things for newly-created ones.
I was thinking of transient domains with no explicit model defined. Prior to this change they would get lsilogic, afterwards virtio-scsi. In practice I doubt there are (m)any such domains in existence.
I don't use transient domains so I might be missing something, but my understanding is that by definition they can't really expect ABI stability to the extent regular domains can since every creation event is independent from the previous ones from libvirt's perspective.
With transient VMs, the mgmt app has to take responsiblility to query the expanded XML and preserve it, if it needs ABI stability. With 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 :|
On 7/3/25 04:35, Daniel P. Berrangé wrote:
On Thu, Jul 03, 2025 at 06:02:38AM -0400, Andrea Bolognani via Devel wrote:
On Wed, Jul 02, 2025 at 02:01:07PM -0600, Jim Fehlig wrote:
On 7/2/25 10:11, Andrea Bolognani wrote:
On Thu, Jun 26, 2025 at 03:29:58PM -0600, Jim Fehlig via Devel wrote:
However, I do understand this change could break existing ARM VM configurations containing a SCSI controller without a model specification. One could also argue the pain inflicted is tolerable :-).
I don't think this should necessarily be a concern.
Unlike, say, USB controllers, where in some cases you could end up with no model recorded in the XML, for SCSI controllers we always either figure out a suitable model or fail defining the domain altogether.
So changing the default here should have no impact on existing domains and simply improve things for newly-created ones.
I was thinking of transient domains with no explicit model defined. Prior to this change they would get lsilogic, afterwards virtio-scsi. In practice I doubt there are (m)any such domains in existence.
I don't use transient domains so I might be missing something, but my understanding is that by definition they can't really expect ABI stability to the extent regular domains can since every creation event is independent from the previous ones from libvirt's perspective.
With transient VMs, the mgmt app has to take responsiblility to query the expanded XML and preserve it, if it needs ABI stability.
Thanks for the clarification. I've pushed the patch. BTW, what do you think about a similar change for x86_64? I vaguely recall the choice of lsilogic for broader Windows support. We checked w2k8r2-w2k25 and win10, none of which contain an LSI Logic driver. virtio-scsi may be a better default for x86_64 as well. Regards, Jim
On Mon, Jul 07, 2025 at 04:45:30PM -0600, Jim Fehlig wrote:
BTW, what do you think about a similar change for x86_64? I vaguely recall the choice of lsilogic for broader Windows support. We checked w2k8r2-w2k25 and win10, none of which contain an LSI Logic driver. virtio-scsi may be a better default for x86_64 as well.
virtio-scsi is always a better default these days, and that's why virt-manager uses it across the board. For libvirt itself, we are forced to be more mindful of historical defaults, even when they're unfortunate. That's why we still use rtl8139 as the default network interface, or indeed lsilogic as the default SCSI controller. We have a bit more leeway on non-x86 platforms because the same long history simply doesn't exist. Arm virt machines were introduced when virtio was already a thing, and effectively they will all be using virtio for everything, regardless of libvirt's defaults. That said, if even Windows is starting to leave devices behind, perhaps the "maximum guest OS compatibility" part of the argument for historical defaults is getting weaker and we're getting closer to a point where we simply have no choice but change them... -- Andrea Bolognani / Red Hat / Virtualization
On Tue, Jul 08, 2025 at 04:59:37AM -0400, Andrea Bolognani wrote:
On Mon, Jul 07, 2025 at 04:45:30PM -0600, Jim Fehlig wrote:
BTW, what do you think about a similar change for x86_64? I vaguely recall the choice of lsilogic for broader Windows support. We checked w2k8r2-w2k25 and win10, none of which contain an LSI Logic driver. virtio-scsi may be a better default for x86_64 as well.
virtio-scsi is always a better default these days, and that's why virt-manager uses it across the board.
For libvirt itself, we are forced to be more mindful of historical defaults, even when they're unfortunate. That's why we still use rtl8139 as the default network interface, or indeed lsilogic as the default SCSI controller.
We have a bit more leeway on non-x86 platforms because the same long history simply doesn't exist. Arm virt machines were introduced when virtio was already a thing, and effectively they will all be using virtio for everything, regardless of libvirt's defaults.
That said, if even Windows is starting to leave devices behind, perhaps the "maximum guest OS compatibility" part of the argument for historical defaults is getting weaker and we're getting closer to a point where we simply have no choice but change them...
Well lsilogic is still offering maximum guest OS compatibility, because for new OS mgmt tools have forever had support to explicitly pick virtio-scsi, and thus no modern guest OS should ever be relying on libvirt's built-in default. The defaults are most likely to be used in scenarios with legacy OS where libosinfo data isn't indicating the use of virtio-scsi. So from that POV I don't think we should change the libvirt defaults here. aarch/riscv are in a much simpler position given they have no need to support any legacy OS which lack virtio With 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 :|
participants (3)
-
Andrea Bolognani -
Daniel P. Berrangé -
Jim Fehlig