[PATCH] lib: Choose q35 machine type for x86-64
This machine type is more modern than the older 'pc' type and as most qemu development is now focused there we expect it will perform and behave better. In almost all respects this change should make no difference. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2168578 --- lib/guestfs-internal.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lib/guestfs-internal.h b/lib/guestfs-internal.h index 07a2b9f617..4e9a103d78 100644 --- a/lib/guestfs-internal.h +++ b/lib/guestfs-internal.h @@ -128,6 +128,9 @@ cleanup_mutex_unlock (pthread_mutex_t **ptr) #define MAX_WINDOWS_EXPLORER_SIZE (4 * 1000 * 1000) /* Machine types. */ +#if defined(__x86_64__) +#define MACHINE_TYPE "q35" +#endif #ifdef __arm__ #define MACHINE_TYPE "virt" #endif -- 2.39.0
On Thu, Feb 09, 2023 at 01:45:33PM +0000, Richard W.M. Jones wrote:
This machine type is more modern than the older 'pc' type and as most qemu development is now focused there we expect it will perform and behave better. In almost all respects this change should make no difference.
The key differences with q35 that have caused problems for apps in the past - CDROMs must use 'sata' bus not 'ide' - PCI topology is completely different, so if you're trying to associate between the host side view of the config and the guest side view, your logic may need adapting - Hotplug of devices is limited to 1 device unless you pre-create a bunch of pcie-root-port devices If you're already using 'virt' machine for aarch64 successfully though, you should have already known about the last 2 points, if they did indeed affect libguestfs. The first point could conceivably affect the way to detect devices, depending on what approach is used, but could equally be a non issue. I presume the libguestfs test suite would have complained if there was any genuine problem with the change, since it is pretty comphrensive.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2168578 --- lib/guestfs-internal.h | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/lib/guestfs-internal.h b/lib/guestfs-internal.h index 07a2b9f617..4e9a103d78 100644 --- a/lib/guestfs-internal.h +++ b/lib/guestfs-internal.h @@ -128,6 +128,9 @@ cleanup_mutex_unlock (pthread_mutex_t **ptr) #define MAX_WINDOWS_EXPLORER_SIZE (4 * 1000 * 1000)
/* Machine types. */ +#if defined(__x86_64__) +#define MACHINE_TYPE "q35" +#endif #ifdef __arm__ #define MACHINE_TYPE "virt" #endif -- 2.39.0
_______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
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 Thu, Feb 09, 2023 at 01:54:42PM +0000, Daniel P. Berrangé wrote:
On Thu, Feb 09, 2023 at 01:45:33PM +0000, Richard W.M. Jones wrote:
This machine type is more modern than the older 'pc' type and as most qemu development is now focused there we expect it will perform and behave better. In almost all respects this change should make no difference.
The key differences with q35 that have caused problems for apps in the past
- CDROMs must use 'sata' bus not 'ide' - PCI topology is completely different, so if you're trying to associate between the host side view of the config and the guest side view, your logic may need adapting - Hotplug of devices is limited to 1 device unless you pre-create a bunch of pcie-root-port devices
If you're already using 'virt' machine for aarch64 successfully though, you should have already known about the last 2 points, if they did indeed affect libguestfs.
The first point could conceivably affect the way to detect devices, depending on what approach is used, but could equally be a non issue.
I presume the libguestfs test suite would have complained if there was any genuine problem with the change, since it is pretty comphrensive.
I ran the full test suite and there were no complaints. In particular we do now do some complicated mapping between PCI and our internal device names[1] and at least the test of that didn't complain. I suspect we could see problems in guestfs-tools, especially things like virt-customize which are running things inside the appliance. For RHEL I have scheduled this change for early in the 9.3 cycle so there is plenty of time to test it. Rich. [1] https://github.com/libguestfs/libguestfs/blob/master/daemon/device-name-tran...
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2168578 --- lib/guestfs-internal.h | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/lib/guestfs-internal.h b/lib/guestfs-internal.h index 07a2b9f617..4e9a103d78 100644 --- a/lib/guestfs-internal.h +++ b/lib/guestfs-internal.h @@ -128,6 +128,9 @@ cleanup_mutex_unlock (pthread_mutex_t **ptr) #define MAX_WINDOWS_EXPLORER_SIZE (4 * 1000 * 1000)
/* Machine types. */ +#if defined(__x86_64__) +#define MACHINE_TYPE "q35" +#endif #ifdef __arm__ #define MACHINE_TYPE "virt" #endif -- 2.39.0
_______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
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 :|
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top
On 2/9/23 14:54, Daniel P. Berrangé wrote:
On Thu, Feb 09, 2023 at 01:45:33PM +0000, Richard W.M. Jones wrote:
This machine type is more modern than the older 'pc' type and as most qemu development is now focused there we expect it will perform and behave better. In almost all respects this change should make no difference.
The key differences with q35 that have caused problems for apps in the past
- CDROMs must use 'sata' bus not 'ide' - PCI topology is completely different, so if you're trying to associate between the host side view of the config and the guest side view, your logic may need adapting - Hotplug of devices is limited to 1 device unless you pre-create a bunch of pcie-root-port devices
If you're already using 'virt' machine for aarch64 successfully though, you should have already known about the last 2 points, if they did indeed affect libguestfs.
The first point could conceivably affect the way to detect devices, depending on what approach is used, but could equally be a non issue.
I presume the libguestfs test suite would have complained if there was any genuine problem with the change, since it is pretty comphrensive.
We still have a direct PCI address reference, after commit range 4af6d68e2d8b..5858c2cf6c24 (RH bug 2034160). It's only supposed to be used on a fallback (very old libvirt) path. I've not found anything similar in the direct backend. I think one thing we could do is compare appliance QEMU cmdlines before/after, and libvirt domain XMLs before/after. We might not catch the corner cases like that, but eventually we'll have to make the switch anyway, and I expect the corner cases will not be hard to fix once they pop up. Acked-by: Laszlo Ersek <lersek@redhat.com> Laszlo
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2168578 --- lib/guestfs-internal.h | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/lib/guestfs-internal.h b/lib/guestfs-internal.h index 07a2b9f617..4e9a103d78 100644 --- a/lib/guestfs-internal.h +++ b/lib/guestfs-internal.h @@ -128,6 +128,9 @@ cleanup_mutex_unlock (pthread_mutex_t **ptr) #define MAX_WINDOWS_EXPLORER_SIZE (4 * 1000 * 1000)
/* Machine types. */ +#if defined(__x86_64__) +#define MACHINE_TYPE "q35" +#endif #ifdef __arm__ #define MACHINE_TYPE "virt" #endif -- 2.39.0
_______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
With regards, Daniel
On Thu, Feb 09, 2023 at 03:34:26PM +0100, Laszlo Ersek wrote:
On 2/9/23 14:54, Daniel P. Berrangé wrote:
On Thu, Feb 09, 2023 at 01:45:33PM +0000, Richard W.M. Jones wrote:
This machine type is more modern than the older 'pc' type and as most qemu development is now focused there we expect it will perform and behave better. In almost all respects this change should make no difference.
The key differences with q35 that have caused problems for apps in the past
- CDROMs must use 'sata' bus not 'ide' - PCI topology is completely different, so if you're trying to associate between the host side view of the config and the guest side view, your logic may need adapting - Hotplug of devices is limited to 1 device unless you pre-create a bunch of pcie-root-port devices
If you're already using 'virt' machine for aarch64 successfully though, you should have already known about the last 2 points, if they did indeed affect libguestfs.
The first point could conceivably affect the way to detect devices, depending on what approach is used, but could equally be a non issue.
I presume the libguestfs test suite would have complained if there was any genuine problem with the change, since it is pretty comphrensive.
We still have a direct PCI address reference, after commit range 4af6d68e2d8b..5858c2cf6c24 (RH bug 2034160). It's only supposed to be used on a fallback (very old libvirt) path. I've not found anything similar in the direct backend.
I think one thing we could do is compare appliance QEMU cmdlines before/after, and libvirt domain XMLs before/after. We might not catch the corner cases like that, but eventually we'll have to make the switch anyway, and I expect the corner cases will not be hard to fix once they pop up.
Acked-by: Laszlo Ersek <lersek@redhat.com>
I will add a link to this thread to the commit so we can reference it in case of any future problems. Rich.
Laszlo
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2168578 --- lib/guestfs-internal.h | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/lib/guestfs-internal.h b/lib/guestfs-internal.h index 07a2b9f617..4e9a103d78 100644 --- a/lib/guestfs-internal.h +++ b/lib/guestfs-internal.h @@ -128,6 +128,9 @@ cleanup_mutex_unlock (pthread_mutex_t **ptr) #define MAX_WINDOWS_EXPLORER_SIZE (4 * 1000 * 1000)
/* Machine types. */ +#if defined(__x86_64__) +#define MACHINE_TYPE "q35" +#endif #ifdef __arm__ #define MACHINE_TYPE "virt" #endif -- 2.39.0
_______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
With regards, Daniel
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html
This is upstream in https://github.com/libguestfs/libguestfs/commit/f0f8e6c5fe0c3f6d5d90534d263b... -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW
On Fri, Feb 10, 2023 at 10:57:40AM +0000, Richard W.M. Jones wrote:
This is upstream in https://github.com/libguestfs/libguestfs/commit/f0f8e6c5fe0c3f6d5d90534d263b...
This is a Fedora Rawhide build: https://koji.fedoraproject.org/koji/taskinfo?taskID=97341784 which if successful will let you mix and match libguestfs 1.51.1 (which includes this patch) with local builds of guestfs-tools, virt-v2v etc. for testing purposes. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v
participants (3)
-
Daniel P. Berrangé -
Laszlo Ersek -
Richard W.M. Jones