Hi Tuomas,
per the guest serial console this seems to be when it initialized the disks.
I tried to reproduce with a guest I had that worked fine on a system
with Luns, and added a lun snippet just like yours (ater making sure
multipath let it go on the host).
<disk type="block" device="lun" rawio="no" sgio="filtered">
<driver name="qemu" type="raw"/>
<source dev="/dev/disk/by-id/wwn-0x6005076306ffd6b60000000000002402"/>
<target dev="sda" bus="scsi"/>
<address type="drive" controller="0" bus="0" target="0" unit="0"/>
</disk>
This auto-adds a controller like:
<controller type='scsi' index='0' model='virtio-scsi'>
<address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0004'/>
</controller>
This matches the one you have (other than the arch difference).
I can't use a trusty guest like you did as the system I had luns
accessible was a mainframe which only started to be supported with
Xenial. So I did xenial and Bionic guests and both worked fine.
Before I go hunting for a different system with a free lun to test I'd have a
few questions to you:
1. could you try if this depends hard on the guest version and or your snapshot
Get a few basic default guests easily via
# will pull in latest daily images
$ uvt-simplestreams-libvirt --verbose sync --source
http://cloud-images.ubuntu.com/daily arch=amd64 label=daily
# will spawn a basic guest based on the cloud images for each release
$ for rel in trusty xenial bionic; do uvt-kvm create --password ubuntu
$rel arch=amd64 release=$rel label=daily; done
# once they booted up and did their first init, shut them all down
# then virsh edit your Lun passthrough snippet
# then start each of them one by one, checking for the disk (lsblk) in
the guest
Q: is the error occurring in these clean Tursty/Xenial/Bionic?
2. On the actual crash I only see in dmesg
[ 9659.700041] qemu-system-x86[26709]: segfault at 4 ip 0000559d63fdba53 sp
00007f6db1de1fb0 error 4 in qemu-system-x86_64[559d639a4000+8d1000]
[ 9659.813263] sdb: sdb1 sdb2 sdb3
[ 9659.816659] sda: sda1 sda2 sda3
[ 9659.819971] sda: sda1 sda2 sda3
That not a lot to check what might have broken, but I assume you get a .crash
file for it.
Please could you try on your system:
run apport on your crash like [2] but with stdout and then report bag the
ouput here as well:
$ apport-retrace --confirm --stdout --sandbox system --verbose --cache
/mypath/cache/apport-retrace --output /mypath/apport-retrace/appname.1000.crash
/var/crash/_usr_bin_appname.1000.crash
If you run into issues [1][3] have many infos on that.
Lacking a repro and without a trace I don't see what I can do, so for
now -> incomplete :-/
[1]:
https://wiki.ubuntu.com/Debug%20Symbol%20Packages#Getting_-dbgsym.ddeb_packages
[2]: https://askubuntu.com/a/348789/532139
[3]: https://wiki.ubuntu.com/Apport
** Changed in: qemu (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1773004
Title:
qemu-system-x86_64 segfaults during guest kernel boot
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1773004/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
