KVM ubuntu 20 VPS on Ryzen 9 5950X with Ubuntu 18.04 on Host is failing to boot

Hi,
the image isn't giving away much - we see something reports a Segmentation Fault but we do not know what or why. I've run similar guests on a few EPYC CPUs that are similar but not the very same. I have right now no access to the same chip you refer to, so I need to ask you to check a few more things.

More detail please:

1. What exactly crashes here ? Since we get more output after the segfault I doubt it is qemu. Is it systemd in the guest - is it a guest process at all? I see "tr" failing, is it just that or more guest processes? What else can you say about it?
2. what exactly is the configuration of the guest, could you share e.g. `virsh dumpxml <guestname>`?
3. could you attach logs as text files instead of images please. For example the guest log in /var/log/libvirt/qemu/<guestname>.log that might help as well.

Check alternatives, to see what makes a difference
Try those and let us know if it makes any difference.

1. I see you use 4.15.0-154-generic on Bionic, you could try the HWE kernel [1]
2. you could try a newer virtualization stack like server-backports [2]
3. you could upgrade your 18.04 system to 20.04 proper and give it a try
4. Vary your guest definition, if you use host-passthrough use something more
   compatible like qemu64 as cpu type (or vice versa). If you have plenty of extra
   features enabled, try disabling them.
5. You tried a 20.04 guest, could you try other guest versions and also not only the ISO,
   maybe the more commonly used cloud images [3]
6. various combinations of the above

[1]: https://wiki.ubuntu.com/Kernel/LTSEnablementStack
[2]: https://launchpad.net/~canonical-server/+archive/ubuntu/server-backports
[3]: http://cloud-images.ubuntu.com/daily/

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Since it seems likely to me that this is a local configuration problem, rather than a bug in Ubuntu, I'm marking this bug as Incomplete.

If indeed this is a local configuration problem, you can find pointers to get help for this sort of problem here: http://www.ubuntu.com/support/community

Or if you believe that this is really a bug, then you may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem, explain why you believe this is a bug in Ubuntu rather than a problem specific to your system, and then change the bug status back to New.

Hi,

Only Ubuntu 20 OS is failing to work on Ubuntu 18 host.
Tried with different CPU modes like pass-through/host-model but did not helped.

xml : https://pastebin.com/1cxUybqt

log : https://pastebin.com/0kh8EuWK

1. What exactly crashes here ? Since we get more output after the segfault I doubt it is qemu.
>> Those those the only messages appearing in vnc

Would it be safe to upgrade to Ubuntu 20 while already hosting vpses on this server ?

> Only Ubuntu 20 OS is failing to work on Ubuntu 18 host.

We've had cases where only certain guest versions would use e.g. some instructions and something like might be broken in this case as well.

So could you confirm that:
- an Ubuntu 18.04 guest in an otherwise same setup works fine?
- an Ubuntu 21.04 guest in an otherwise same setup works fine as well?

> Tried with different CPU modes like pass-through/host-model but did not helped.

Those are both rather powerful (many features) have you tried a weak one with only basic features?

<cpu mode='custom'>
    <model fallback='forbid'>qemu64</model>
</cpu>

> xml : https://pastebin.com/1cxUybqt

Host-passthrough is definitely the most powerful, but also the least safe/compatible one.
As I said above try with qemu64 and if working enable features one by one until we found the one that breaks you.

> Those those the only messages appearing in vnc
+
> log : https://pastebin.com/0kh8EuWK

Well, they need to come from somewhere. If it would be qemu that crashed your VNC connection would have terminated. Also the log does not report qemu crashes (they'd be there).
So we can assume - to some extent - that it is guest processes that fail.

[Expired for qemu (Ubuntu) because there has been no activity for 60 days.]