Public bug reported:
I have discussed this with the s390x developers and the consensus was to report
that upstream.
I'll do that but also keep a bug open for tracking here.
If migrating a guest that was initially started on Xenial (qemu 2.5) to
a new virtualization stack (qemu 4.2 libvirt 6.0) it fails.
The reason is that the old system has defined the machine type of the time e.g.
machine type: s390-ccw-virtio-2.5
The matching commandline is part:
-machine s390-ccw-virtio-2.5,accel=kvm,usb=off
-cpu (not present here)
But on the migration to the new stack this becomes:
-machine s390-ccw-virtio-2.5,accel=kvm,usb=off (kept from the source of the
migration)
-cpu z13-base,aen=on,aefsi=on,... (modelled on the target)
The problem is that s390x prior to qemu 2.8 had no cpu modelling.
Therefore it fails with:
qemu-system-s390x: CPU models are not available: KVM doesn't support CPU
models
Source XML:
<domain type='kvm' id='3'>
<name>x-guest2</name>
<uuid>c4545c20-5415-4f2c-86c7-df77eab1f6bb</uuid>
<memory unit='KiB'>524288</memory>
<currentMemory unit='KiB'>524288</currentMemory>
<vcpu placement='static'>1</vcpu>
<resource>
<partition>/machine</partition>
</resource>
<os>
<type arch='s390x' machine='s390-ccw-virtio-2.5'>hvm</type>
<boot dev='hd'/>
</os>
<features>
<acpi/>
<apic/>
<pae/>
</features>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<devices>
<emulator>/usr/bin/qemu-system-s390x</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/uvtool/libvirt/images/x-guest2.qcow'/>
<backingStore type='file' index='1'>
<format type='qcow2'/>
<source
file='/var/lib/uvtool/libvirt/images/x-uvt-b64-Y29tLnVidW50dS5jbG91ZC5kYWlseTpzZXJ2ZXI6MTYuMDQ6czM5MHggMjAyMDAxMjE='/>
<backingStore/>
</backingStore>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0000'/>
</disk>
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/var/lib/uvtool/libvirt/images/x-guest2-ds.qcow'/>
<backingStore/>
<target dev='vdb' bus='virtio'/>
<alias name='virtio-disk1'/>
<address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0001'/>
</disk>
<interface type='network'>
<mac address='52:54:00:39:e7:fb'/>
<source network='default' bridge='virbr0'/>
<target dev='vnet1'/>
<model type='virtio'/>
<alias name='net0'/>
<address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0002'/>
</interface>
<console type='pty' tty='/dev/pts/1'>
<source path='/dev/pts/1'/>
<target type='sclp' port='0'/>
<alias name='console0'/>
</console>
<memballoon model='virtio'>
<alias name='balloon0'/>
<address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0003'/>
</memballoon>
</devices>
<seclabel type='dynamic' model='apparmor' relabel='yes'>
<label>libvirt-c4545c20-5415-4f2c-86c7-df77eab1f6bb</label>
<imagelabel>libvirt-c4545c20-5415-4f2c-86c7-df77eab1f6bb</imagelabel>
</seclabel>
</domain>
Source log/commandline:
2020-01-28 13:58:28.719+0000: starting up libvirt version: 1.3.1, package:
1ubuntu10.29 (Matthew Ruffell <matthew.ruff...@canonical.com> Thu, 31 Oct 2019
10:52:41 +1300), qemu version: 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.42),
hostname: testkvm-xenial-from
LC_ALL=C
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
QEMU_AUDIO_DRV=none /usr/bin/qemu-system-s390x -name x-guest2 -S -machine
s390-ccw-virtio-2.5,accel=kvm,usb=off -m 512 -realtime mlock=off -smp
1,sockets=1,cores=1,threads=1 -uuid c4545c20-5415-4f2c-86c7-df77eab1f6bb
-nographic -no-user-config -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-x-guest2/monitor.sock,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown
-boot strict=on -drive
file=/var/lib/uvtool/libvirt/images/x-guest2.qcow,format=qcow2,if=none,id=drive-virtio-disk0
-device
virtio-blk-ccw,scsi=off,devno=fe.0.0000,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-drive
file=/var/lib/uvtool/libvirt/images/x-guest2-ds.qcow,format=raw,if=none,id=drive-virtio-disk1
-device
virtio-blk-ccw,scsi=off,devno=fe.0.0001,drive=drive-virtio-disk1,id=virtio-disk1
-netdev tap,fd=25,id=hostnet0 -device
virtio-net-ccw,netdev=hostnet0,id=net0,mac=52:54:00:39:e7:fb,devno=fe.0.0002
-chardev pty,id=charconsole0 -device
sclpconsole,chardev=charconsole0,id=console0 -device
virtio-balloon-ccw,id=balloon0,devno=fe.0.0003 -msg timestamp=on
char device redirected to /dev/pts/1 (label charconsole0)
Target log/commandline:
2020-01-28 13:59:04.396+0000: starting up libvirt version: 6.0.0, package:
0ubuntu1~ppa2 (Christian Ehrhardt <christian.ehrha...@canonical.com> Mon, 13
Jan 2020 13:14:14 +0100), qemu version: 4.2.0Debian 1:4.2-1ubuntu1~ppa4,
kernel: 5.4.0-9-generic, hostname: testkvm-focal-to
LC_ALL=C \
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin \
HOME=/var/lib/libvirt/qemu/domain-3-x-guest2 \
XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-3-x-guest2/.local/share \
XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-3-x-guest2/.cache \
XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-3-x-guest2/.config \
QEMU_AUDIO_DRV=none \
/usr/bin/qemu-system-s390x \
-name guest=x-guest2,debug-threads=on \
-S \
-object
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-3-x-guest2/master-key.aes
\
-machine s390-ccw-virtio-2.5,accel=kvm,usb=off,dump-guest-core=off \
-cpu
z13-base,aen=on,aefsi=on,msa5=on,msa4=on,msa3=on,msa2=on,msa1=on,sthyi=on,edat=on,ri=on,edat2=on,vx=on,ipter=on,cei=on,ap=on,gpereh=on,esop=on,ib=on,siif=on,ibs=on,apqi=on,apft=on,sief2=on,apqci=on,cte=on,bpb=on,64bscao=on,ppa15=on,zpci=on,sea_esop2=on,te=on,cmm=on,gsls=on
\
-m 512 \
-overcommit mem-lock=off \
-smp 1,sockets=1,cores=1,threads=1 \
-uuid c4545c20-5415-4f2c-86c7-df77eab1f6bb \
-display none \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,fd=30,server,nowait \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc \
-no-shutdown \
-boot strict=on \
-blockdev
'{"driver":"file","filename":"/var/lib/uvtool/libvirt/images/x-uvt-b64-Y29tLnVidW50dS5jbG91ZC5kYWlseTpzZXJ2ZXI6MTYuMDQ6czM5MHggMjAyMDAxMjE=","node-name":"libvirt-3-storage","auto-read-only":true,"discard":"unmap"}'
\
-blockdev
'{"node-name":"libvirt-3-format","read-only":true,"driver":"qcow2","file":"libvirt-3-storage","backing":null}'
\
-blockdev
'{"driver":"file","filename":"/var/lib/uvtool/libvirt/images/x-guest2.qcow","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}'
\
-blockdev
'{"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":"libvirt-3-format"}'
\
-device
virtio-blk-ccw,scsi=off,devno=fe.0.0000,drive=libvirt-2-format,id=virtio-disk0,bootindex=1
\
-blockdev
'{"driver":"file","filename":"/var/lib/uvtool/libvirt/images/x-guest2-ds.qcow","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}'
\
-blockdev
'{"node-name":"libvirt-1-format","read-only":false,"driver":"raw","file":"libvirt-1-storage"}'
\
-device
virtio-blk-ccw,scsi=off,devno=fe.0.0001,drive=libvirt-1-format,id=virtio-disk1 \
-netdev tap,fd=32,id=hostnet0 \
-device
virtio-net-ccw,netdev=hostnet0,id=net0,mac=52:54:00:39:e7:fb,devno=fe.0.0002 \
-chardev pty,id=charconsole0 \
-device sclpconsole,chardev=charconsole0,id=console0 \
-incoming defer \
-device virtio-balloon-ccw,id=balloon0,devno=fe.0.0003 \
-sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
-msg timestamp=on
char device redirected to /dev/pts/0 (label charconsole0)
2020-01-28T13:59:04.627166Z qemu-system-s390x: CPU models are not available:
KVM doesn't support CPU models
2020-01-28 13:59:04.807+0000: shutting down, reason=failed
Migration command:
$ virsh migrate --live x-guest2 qemu+ssh://10.226.99.253/system
After checking the above I found that this isn't even tied to migration which
would have been my first assumption.
The following two together in a domain XML lead to the same error:
<cpu mode='host-model' check='partial'/>
<type arch='s390x' machine='s390-ccw-virtio-2.5'>hvm</type>
It turns out that
<cpu mode='host-model' check='partial'/>
is the default.
So when I define the following:
$ cat breakme.xml
<domain type='kvm'>
<name>breakme</name>
<memory unit='KiB'>524288</memory>
<os>
<type arch='s390x' machine='s390-ccw-virtio-2.5'>hvm</type>
</os>
</domain>
$ virsh define breakme.xml
Domain breakme defined from breakme.xml
I get cpu + old-type:
root@testkvm-focal-to:~# virsh dumpxml breakme
<domain type='kvm'>
<name>breakme</name>
<uuid>b2b5dc0c-1e95-49fd-8168-80fcbfeca6af</uuid>
<memory unit='KiB'>524288</memory>
<currentMemory unit='KiB'>524288</currentMemory>
<vcpu placement='static'>1</vcpu>
<os>
<type arch='s390x' machine='s390-ccw-virtio-2.5'>hvm</type>
<boot dev='hd'/>
</os>
<cpu mode='host-model' check='partial'/>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<devices>
<emulator>/usr/bin/qemu-system-s390x</emulator>
<controller type='pci' index='0' model='pci-root'/>
<memballoon model='virtio'>
<address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0000'/>
</memballoon>
<panic model='s390'/>
</devices>
</domain>
And that breaks on start:
# virsh start breakme
error: Failed to start domain breakme
error: internal error: qemu unexpectedly closed the monitor:
2020-01-28T14:37:27.477232Z qemu-system-s390x: CPU models are not available:
KVM doesn't support CPU models
I see no way to remove
<cpu mode='host-model' check='partial'/>
as it is automatically added back.
Adding this section by default (I guess) needs to be avoided when the
underlying machine type (anything prior to s390-ccw-virtio-2.8 or even a bit
more) is in use.
Then creating guests would not model cpus like
-cpu ...
and that would work with the old type which implicitly did something like -cpu
host.
On that note, host-passthrough existed back then.
And making the guest definition to hold
<cpu mode='host-passthrough'/>
makes it work.
So older types might want that (instead of nothing)
Works:
$ cat works.xml
<domain type='kvm'>
<name>breakme</name>
<memory unit='KiB'>524288</memory>
<cpu mode='host-passthrough'/>
<os>
<type arch='s390x' machine='s390-ccw-virtio-2.5'>hvm</type>
</os>
</domain>
What do you think about some compat check on machine-type version vs the
auto-addition of cpu host-model that didn't work back then?
** Affects: libvirt
Importance: Unknown
Status: Unknown
** Affects: libvirt (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1861125
Title:
s390x can't migrate pre qemu 2.8 to qemu4.2/libvirt6.0 (X->F)
To manage notifications about this bug go to:
https://bugs.launchpad.net/libvirt/+bug/1861125/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
