qemu-kvm: virt-install VM fails due to inconsistent virsh capabilities output due to multiple qemu instance
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
qemu (Debian) |
Fix Released
|
Unknown
|
|||
qemu (Ubuntu) |
Won't Fix
|
Low
|
Taco Screen team |
Bug Description
== Comment: #0 - Satheesh Rajendran <email address hidden> - 2016-09-26 07:12:52 ==
---Problem Description---
VM creation fails for wrong machine type from virt-install.
From the initial debugging it looks like pseries-2.7 is not listed as a supported machine type from qemu-system-ppc64 but the virsh capabilities lists as default, hence virt-install ended in choosing pseries-2.7 and qemu complains as unsupported type.
may be pseries-2.7 is renamed to pseries-yakkety? which needs a change in capabilities?
Contact Information = <email address hidden>
---uname output---
Linux ltc-test-ci1 4.8.0-17-generic #19-Ubuntu SMP Sun Sep 25 06:35:40 UTC 2016 ppc64le ppc64le ppc64le GNU/Linux
Machine Type = power 8 ppc64le
---Debugger---
A debugger is not configured
---Steps to Reproduce---
/usr/
Starting install...
ERROR internal error: process exited while connecting to monitor: 2016-09-
Use -machine help to list supported machines
Domain installation does not appear to have been successful.
If it was, you can restart your domain by running:
virsh --connect qemu:///system start vm1
otherwise, please restart your installation.
#qemu-system-ppc64 -machine ?
Supported machines are:
bamboo bamboo
g3beige Heathrow based PowerMAC
mac99 Mac99 based PowerMAC
mpc8544ds mpc8544ds
none empty machine
ppce500 generic paravirt e500 platform
prep PowerPC PREP platform
pseries-2.1 pSeries Logical Partition (PAPR compliant)
pseries-2.2 pSeries Logical Partition (PAPR compliant)
pseries-2.3 pSeries Logical Partition (PAPR compliant)
pseries-2.4 pSeries Logical Partition (PAPR compliant)
pseries-2.5 pSeries Logical Partition (PAPR compliant)
pseries-2.6 pSeries Logical Partition (PAPR compliant)
pseries-xenial pSeries Logical Partition (PAPR compliant)
pseries pSeries Logical Partition (PAPR compliant) (alias of pseries-yakkety)
pseries-yakkety pSeries Logical Partition (PAPR compliant) (default)
ref405ep ref405ep
taihu taihu
virtex-ml507 Xilinx Virtex ML507 reference design
#virsh capabilities
....
....
<guest>
<os_
<arch name='ppc64le'>
<
<
<machine maxCpus=
<machine canonical=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<domain type='qemu'/>
<domain type='kvm'>
<machine maxCpus=
<machine canonical=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
<machine maxCpus=
</domain>
</arch>
<features>
<
<deviceboot/>
<disksnapshot default='on' toggle='no'/>
</features>
</guest>
Userspace tool common name: ii qemu-system-ppc 1:2.6.1+
The userspace tool has the following bit modes: both
Userspace rpm: ii qemu-system-ppc 1:2.6.1+
Userspace tool obtained from project website: na
*Additional Instructions for <email address hidden>:
-Post a private note with access information to the machine that the bug is occuring on.
-Attach ltrace and strace of userspace application.
== Comment: #1 - Satheesh Rajendran <email address hidden> - 2016-09-26 09:17:32 ==
There was a local qemu-system-ppc64 instance and due to /usr/bin/kvm defaults to local qemu-system-ppc64 instance there was inconsistent in virsh capabilities output, even after removing the local qemu-system-ppc64 instance.
Had a discussion with Shiva, after removing libvirt cache, libvirt restart the virsh capabilities output became consistent
== Comment: #2 - Shivaprasad G. Bhat <email address hidden> - 2016-09-26 09:19:41 ==
Just to add, the binary in wrapper better be an absolute path that way, there is never an inconsistency over PATH variable changes
== Comment: #3 - Satheesh Rajendran <email address hidden> - 2016-09-26 09:26:21 ==
To avoid this behavior permanently, it is good to the absolute path for qemu-system-ppc64 in /usr/bin/kvm wrapper,
#!/bin/sh
set -f
getcpu() {
CPU="unknown"
[ -r /proc/cpuinfo ] || return
local line
while read line; do
set -- $line
[ "$1" = "cpu" ] && CPU="$3" && return 0;
done < /proc/cpuinfo
return
}
getcpu
case "$CPU" in
e500*
qemu=
;;
*)
case "" in
ppc64*)
;;
*)
;;
esac
;;
esac
exec "$qemu" -enable-kvm "$@"
tags: | added: architecture-ppc64le bugnameltc-146735 severity-high targetmilestone-inin1610 |
Changed in ubuntu: | |
assignee: | nobody → Taco Screen team (taco-screen-team) |
affects: | ubuntu → qemu (Ubuntu) |
Changed in qemu (Debian): | |
status: | Unknown → New |
Changed in qemu (Debian): | |
status: | New → Fix Released |
Likely related to https:/ /bugs.launchpad .net/ubuntu/ +source/ qemu/+bug/ 1626070