1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
<think>
Alright, let me try to figure out how to classify this bug report. So, the user is experiencing a segfault in QEMU when they start virt-manager. They've provided details about their setup, including versions of libvirtd, virt-manager, and qemu.
Looking at step 2, they started a VM manually using virsh, which launched a QEMU instance with several devices and configurations. Then, in step 3, they started virt-manager normally, and the QEMU process crashed with a segfault.
The possible categories are: mistranslation, assembly, other, device, graphic, socket, network, KVM, boot, vnc, debug, files, permissions, performance, kernel, peripherals, hypervisor.
Hmm. Segfaults can happen for various reasons. Since it's happening when starting virt-manager after a VM is already running, maybe there's an interaction between virt-manager and the existing QEMU instance. Or perhaps virt-manager tries to connect or manage the VM in a way that causes QEMU to crash.
Looking at the command line arguments for QEMU, I see several devices are being used: USB controllers, VirtIO devices, serial ports, VGA, sound, etc. Also, VNC and Spice are involved because of the -vnc and qxl-vga options.
The segfault could be related to how virt-manager interacts with these devices or the hypervisor (since KVM is mentioned). Maybe there's a problem in the way VirtIO devices are handled or some race condition when virt-manager starts while QEMU is already running. Alternatively, it might be a bug in the graphical interfaces setup, like Spice or VNC.
Since the backtrace isn't provided, it's hard to pinpoint, but considering the options, 'hypervisor' seems relevant because KVM is part of the system and any issue with how the hypervisor handles VMs could cause QEMU to crash. Alternatively, if it's related to device management or graphical interfaces, 'device' or 'graphic' might be appropriate.
But given that KVM is explicitly mentioned in the command line as accel=kvm, and the overall environment involves virtualization, I think the most fitting category is 'hypervisor'. It could be a bug in how QEMU's hypervisor component interacts with virt-manager when multiple instances are running or being managed.
</think>
hypervisor
|