RE: External snapshots and using qemu without libvirt

2021-09-13 Thread Leek, Jim
Thanks for your suggestion.  I had gotten the command line from the libvirt log 
file, but I ran the ps fax check as a comparison.  There was no meaningful 
difference between what was in the log file and on the command line.

So I looked at other options and tried a bunch of -display options.  Many of 
them don't work with the version of qemu that comes installed on RHEL 8, qemu 
gtk, etc. didn't work.

I am able to get a spice server up and connect to it.  But the spice-screen 
remains black.  If I kill the qemu process it disconnects, so it's definitely 
the correct spice server.   ANyone see that issue before?  (If I put on "-vnc 
:0"  the vnc client will tell me "client has not initialized the display (yet)")

Jim

-Original Message-
From: Qemu-discuss  On Behalf 
Of Simon Becherer
Sent: Monday, September 13, 2021 8:20 AM
To: qemu-discuss@nongnu.org
Subject: Re: External snapshots and using qemu without libvirt



Am 13.09.21 um 16:34 schrieb Leek, Jim:
> I'm still messing about with qemu snapshots.  I have internal snapshots 
> working OK.  But I read this in the RHEL documentation: "Important: Red Hat 
> recommends the use of external snapshots." Then on a later page I found this: 
> "However, external snapshots are currently not fully implemented on Red Hat 
> Enterprise Linux 7, and are not available when using virt-manager."Ha!
> 
> Maybe external snapshots will work if I run qemu without libvirt? But 
> I'm having trouble getting that to work as well.  I found this page 
> and followed the instructions: 
> https://developers.redhat.com/blog/2020/03/06/configure-and-run-a-qemu
> -based-vm-outside-of-libvirt (although he talks about 
> qemu-system-x86_64 and I'm using qemu-kvm, but I hope that doesn't 
> make any difference.)
> 
> But I can't get it to work.  I've tried a number of modifications, and the 
> command line below launches the VM, but I can't access it.  No screen pops 
> up, and I can't get there via ssh.  If I take off the last lines about the 
> display it will say I can use VNC ::1:5900, but when I connect there it with 
> a VNC client it just says "guest has not initialized display yet."
> 
> Anybody have any ideas on any of this?
> Thanks
> 
> Here's the command line I've tried.  The removing the last 2 arguments does 
> change the display behavior, but not to any particular benefit:
> #! /bin/sh
> export LC_ALL=C
> export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
> export HOME=/var/lib/libvirt/qemu/domain-6-centos8_3
> export 
> XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-6-centos8_3/.local/share
> export XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-6-centos8_3/.cache
> export 
> XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-6-centos8_3/.config
> export QEMU_AUDIO_DRV=spice
> /usr/libexec/qemu-kvm \
> -name guest=centos8_3,debug-threads=on \ -S \ -enable-fips \ -machine 
> pc-q35-rhel8.2.0,accel=kvm,usb=off,vmport=off,dump-guest-core=off \ 
> -cpu 
> Skylake-Server-IBRS,ss=on,vmx=on,pdcm=on,hypervisor=on,tsc-adjust=on,c
> lflushopt=on,umip=on,pku=on,md-clear=on,stibp=on,arch-capabilities=on,
> ssbd=on,xsaves=on,ibpb=on,ibrs=on,amd-stibp=on,amd-ssbd=on,skip-l1dfl-
> vmentry=on,pschange-mc-no=on \ -m 24000 \ -overcommit mem-lock=off \ 
> -smp 2,sockets=2,cores=1,threads=1 \ -uuid 
> 8dd20f24-3e31-464c-956e-67d3d9f2a83c \ -no-user-config \ -rtc 
> base=utc,driftfix=slew \ -global kvm-pit.lost_tick_policy=delay \ 
> -no-hpet \ -no-shutdown \ -global ICH9-LPC.disable_s3=1 \ -global 
> ICH9-LPC.disable_s4=1 \ -boot strict=on \ -device 
> pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=o
> n,addr=0x2 \ -device 
> pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \ 
> -device 
> pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \ 
> -device 
> pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \ 
> -device 
> pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \ 
> -device 
> pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 \ 
> -device 
> pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x6 \ 
> -device 
> pcie-root-port,port=0x17,chassis=8,id=pci.8,bus=pcie.0,addr=0x2.0x7 \ 
> -device pcie-pci-bridge,id=pci.9,bus=pci.1,addr=0x0 \ -device 
> qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 \ -device 
> virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 \ -blockdev 
> '{"driver":"file","filename":"/home/leek2/qemu/rhel8_1-clone-1.qcow2",
> "node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap
> "}' \ -blockdev 
> '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","f
> ile":"libvirt-1-storage","backing":null}' \ -device 
> virtio-blk-pci,scsi=off,bus=pci.4,addr=0x0,drive=libvirt-1-format,id=v
> irtio-disk0,bootindex=1 \ -device 
> virtio-net-pci,netdev=hostnet0,id=net0,mac=6c:2b:59:e9:44:49,bus=pci.7
> ,addr=0x0 \ -netdev bridge,id=hostnet0,br=virbr0 \ -chardev 
> spicevmc,id=charchannel0,name=vdagent \ 

Re: External snapshots and using qemu without libvirt

2021-09-13 Thread Simon Becherer


Am 13.09.21 um 16:34 schrieb Leek, Jim:
> I'm still messing about with qemu snapshots.  I have internal snapshots 
> working OK.  But I read this in the RHEL documentation: "Important: Red Hat 
> recommends the use of external snapshots." Then on a later page I found this: 
> "However, external snapshots are currently not fully implemented on Red Hat 
> Enterprise Linux 7, and are not available when using virt-manager."Ha!
> 
> Maybe external snapshots will work if I run qemu without libvirt? But I'm 
> having trouble getting that to work as well.  I found this page and followed 
> the instructions: 
> https://developers.redhat.com/blog/2020/03/06/configure-and-run-a-qemu-based-vm-outside-of-libvirt
>  (although he talks about qemu-system-x86_64 and I'm using qemu-kvm, but I 
> hope that doesn't make any difference.)
> 
> But I can't get it to work.  I've tried a number of modifications, and the 
> command line below launches the VM, but I can't access it.  No screen pops 
> up, and I can't get there via ssh.  If I take off the last lines about the 
> display it will say I can use VNC ::1:5900, but when I connect there it with 
> a VNC client it just says "guest has not initialized display yet."
> 
> Anybody have any ideas on any of this?
> Thanks
> 
> Here's the command line I've tried.  The removing the last 2 arguments does 
> change the display behavior, but not to any particular benefit:
> #! /bin/sh 
> export LC_ALL=C 
> export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin 
> export HOME=/var/lib/libvirt/qemu/domain-6-centos8_3 
> export XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-6-centos8_3/.local/share 
> export XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-6-centos8_3/.cache 
> export XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-6-centos8_3/.config 
> export QEMU_AUDIO_DRV=spice 
> /usr/libexec/qemu-kvm \
> -name guest=centos8_3,debug-threads=on \
> -S \
> -enable-fips \
> -machine pc-q35-rhel8.2.0,accel=kvm,usb=off,vmport=off,dump-guest-core=off \
> -cpu 
> Skylake-Server-IBRS,ss=on,vmx=on,pdcm=on,hypervisor=on,tsc-adjust=on,clflushopt=on,umip=on,pku=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaves=on,ibpb=on,ibrs=on,amd-stibp=on,amd-ssbd=on,skip-l1dfl-vmentry=on,pschange-mc-no=on
>  \
> -m 24000 \
> -overcommit mem-lock=off \
> -smp 2,sockets=2,cores=1,threads=1 \
> -uuid 8dd20f24-3e31-464c-956e-67d3d9f2a83c \
> -no-user-config \
> -rtc base=utc,driftfix=slew \
> -global kvm-pit.lost_tick_policy=delay \
> -no-hpet \
> -no-shutdown \
> -global ICH9-LPC.disable_s3=1 \
> -global ICH9-LPC.disable_s4=1 \
> -boot strict=on \
> -device 
> pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2
>  \
> -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \
> -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \
> -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \
> -device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \
> -device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 \
> -device pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x6 \
> -device pcie-root-port,port=0x17,chassis=8,id=pci.8,bus=pcie.0,addr=0x2.0x7 \
> -device pcie-pci-bridge,id=pci.9,bus=pci.1,addr=0x0 \
> -device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 \
> -device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 \
> -blockdev 
> '{"driver":"file","filename":"/home/leek2/qemu/rhel8_1-clone-1.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}'
>  \
> -blockdev 
> '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}'
>  \
> -device 
> virtio-blk-pci,scsi=off,bus=pci.4,addr=0x0,drive=libvirt-1-format,id=virtio-disk0,bootindex=1
>  \
> -device 
> virtio-net-pci,netdev=hostnet0,id=net0,mac=6c:2b:59:e9:44:49,bus=pci.7,addr=0x0
>  \
> -netdev bridge,id=hostnet0,br=virbr0 \
> -chardev spicevmc,id=charchannel0,name=vdagent \
> -device 
> virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
>  \
> -device virtio-balloon-pci,id=balloon0,bus=pci.5,addr=0x0 \
> -object rng-random,id=objrng0,filename=/dev/urandom \
> -device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.6,addr=0x0 \
> -msg timestamp=on \
> -device 
> qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1
>  \
> -spice 
> port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on
> 


Without checking all of your config:
> -spice 
> port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on
should be: disable-ticketing=on

i would suggest you fire up your quemu with libvirt and then check the 
generated startline
with
ps fax |grep qemu

regards,

simoN

-- 
www.becherer.de





signature.asc
Description: OpenPGP digital signature


External snapshots and using qemu without libvirt

2021-09-13 Thread Leek, Jim
I'm still messing about with qemu snapshots.  I have internal snapshots working 
OK.  But I read this in the RHEL documentation: "Important: Red Hat recommends 
the use of external snapshots." Then on a later page I found this: "However, 
external snapshots are currently not fully implemented on Red Hat Enterprise 
Linux 7, and are not available when using virt-manager."Ha!

Maybe external snapshots will work if I run qemu without libvirt? But I'm 
having trouble getting that to work as well.  I found this page and followed 
the instructions: 
https://developers.redhat.com/blog/2020/03/06/configure-and-run-a-qemu-based-vm-outside-of-libvirt
 (although he talks about qemu-system-x86_64 and I'm using qemu-kvm, but I hope 
that doesn't make any difference.)

But I can't get it to work.  I've tried a number of modifications, and the 
command line below launches the VM, but I can't access it.  No screen pops up, 
and I can't get there via ssh.  If I take off the last lines about the display 
it will say I can use VNC ::1:5900, but when I connect there it with a VNC 
client it just says "guest has not initialized display yet."

Anybody have any ideas on any of this?
Thanks

Here's the command line I've tried.  The removing the last 2 arguments does 
change the display behavior, but not to any particular benefit:
#! /bin/sh 
export LC_ALL=C 
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin 
export HOME=/var/lib/libvirt/qemu/domain-6-centos8_3 
export XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-6-centos8_3/.local/share 
export XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-6-centos8_3/.cache 
export XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-6-centos8_3/.config 
export QEMU_AUDIO_DRV=spice 
/usr/libexec/qemu-kvm \
-name guest=centos8_3,debug-threads=on \
-S \
-enable-fips \
-machine pc-q35-rhel8.2.0,accel=kvm,usb=off,vmport=off,dump-guest-core=off \
-cpu 
Skylake-Server-IBRS,ss=on,vmx=on,pdcm=on,hypervisor=on,tsc-adjust=on,clflushopt=on,umip=on,pku=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaves=on,ibpb=on,ibrs=on,amd-stibp=on,amd-ssbd=on,skip-l1dfl-vmentry=on,pschange-mc-no=on
 \
-m 24000 \
-overcommit mem-lock=off \
-smp 2,sockets=2,cores=1,threads=1 \
-uuid 8dd20f24-3e31-464c-956e-67d3d9f2a83c \
-no-user-config \
-rtc base=utc,driftfix=slew \
-global kvm-pit.lost_tick_policy=delay \
-no-hpet \
-no-shutdown \
-global ICH9-LPC.disable_s3=1 \
-global ICH9-LPC.disable_s4=1 \
-boot strict=on \
-device 
pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2
 \
-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \
-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \
-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \
-device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \
-device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 \
-device pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x6 \
-device pcie-root-port,port=0x17,chassis=8,id=pci.8,bus=pcie.0,addr=0x2.0x7 \
-device pcie-pci-bridge,id=pci.9,bus=pci.1,addr=0x0 \
-device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 \
-blockdev 
'{"driver":"file","filename":"/home/leek2/qemu/rhel8_1-clone-1.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}'
 \
-blockdev 
'{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}'
 \
-device 
virtio-blk-pci,scsi=off,bus=pci.4,addr=0x0,drive=libvirt-1-format,id=virtio-disk0,bootindex=1
 \
-device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=6c:2b:59:e9:44:49,bus=pci.7,addr=0x0 
\
-netdev bridge,id=hostnet0,br=virbr0 \
-chardev spicevmc,id=charchannel0,name=vdagent \
-device 
virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
 \
-device virtio-balloon-pci,id=balloon0,bus=pci.5,addr=0x0 \
-object rng-random,id=objrng0,filename=/dev/urandom \
-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.6,addr=0x0 \
-msg timestamp=on \
-device 
qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1
 \
-spice 
port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on



Problem with init debugging under QEMU ARM

2021-09-13 Thread Lukasz Majewski
Dear QEMU community,

I'm now trying to fix bug in glibc which became apparent on qemu 6.0.0.

The error is caused by glibc commit:
bca0f5cbc9257c13322b99e55235c4f21ba0bd82
https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=sysdeps/arm/dl-machine.h;h=eb13cb8b57496a0ec175c54a495f7e78db978fb7;hp=ff5e09e207f7986b1506b8895ae6c2aff032a380;hb=bca0f5cbc9257c13322b99e55235c4f21ba0bd82;hpb=34b4624b04fc8f038b2c329ca7560197320615b4

(reverting it causes the board to boot again)

Other components:
binutils_2.37
gcc_11.2
Yocto poky: SHA1: 1e2e9a84d6dd81d7f6dd69c0d119d0149d10ade1

Qemu start line (the problem is visible on 5.2.0 and 6.0.0):
qemu-system-arm -device
virtio-net-device,netdev=net0,mac=52:54:00:12:34:02 -netdev
tap,id=net0,ifnam e=tap0,script=no,downscript=no -object
rng-random,filename=/dev/urandom,id=rng0 -device
virtio-rng-pci,rng=rng0 -drive
id=disk0,file=y2038-image-devel-qemuarm.ext4,if=none,format
=raw -device virtio-blk-device,drive=disk0 -device qemu-xhci -device
usb-tablet -device usb-kbd  -machine virt,highmem=off -cpu cortex-a15
-smp 4 -m 256 -serial mon:stdio -serial null -nographic -device
VGA,edid=on -kernel
zImage--5.10.62+git0+bce2813b16_machine-r0-qemuarm-20210910095636.bin
-append 'root=/dev/vda rw  mem=256M
ip=192.168.7.2::192.168.7.1:255.255.255.0 console=ttyAMA0 console=hvc0
vmalloc=256


It has been tested with Cortex-A9 (Vexpress A9 2 core board) and
Cortex-A15. I've also tested the v5.1, v5.10 and v5.14 kernels. The
error is persistent.

I do add -s and -S when starting qemu-system-arm. I can use gdb to
debug the kernel without issues. Unfortunately, I'm not able to debug
/sbin/init after switching contex to user space.

Moreover, gdbserver cannot be used as the error (and kernel OOPs) is
caused when early code from ld-linux.so.3 (the _dl_start function) is
executed.


Any hints on how to debug it?

Inspecting assembler is one (awkward) option (some results presented
below). I can also inspect the VMA of the code just before starting the
/sbin/init process.

Unfortunately, when I try to break on user space code it is not very
helpful (as -S -s are supposed to be used with kernel).


Some info with the eligible code (_dl_start function):
--

I think that the problem may be with having the negative value
calculated.

The relevant snipet:

116c:   bf00nop
116e:   bf00nop
1170:   bf00nop
1172:   f8df 3508   ldr.w   r3, [pc, #1288] ; 167c
<_dl_start+0x520>

1176:   f8df 1508   ldr.w   r1, [pc, #1288] ; 1680
<_dl_start+0x524>

117a:   447badd r3, pc
117c:   4479add r1, pc
117e:   f8c3 1598   str.w   r1, [r3, #1432] ; 0x598
1182:   bf00nop
1184:   bf00nop
1186:   bf00nop
1188:   bf00nop
118a:   bf00nop
118c:   bf00nop
118e:   f8df 24f4   ldr.w   r2, [pc, #1268] ; 1684
<_dl_start+0x528> 1192:   f8d3 5598   ldr.w   r5, [r3,
#1432] ; 0x598 1196:   447aadd r2, pc
1198:   442aadd r2, r5
119a:   1a52subsr2, r2, r1
119c:   f8c3 25a0   str.w   r2, [r3, #1440] ; 0x5a0
11a0:   6813ldr r3, [r2, #0]


167c:   0002be92.word   0x0002be92
1680:   ee80.word   0xee80

The r1 gets the 0xee80 (negative offset) value. It is then added to
pc and used to calculate r2.

For working code (aforementioned patch reverted) - there are NO such
large values (like aforementioned 0xee80). The arithmetic is done
on 

   1690:   0020.word   0x0020
   1694:   0002be7e.word   0x0002be7e

which seems to work.

Maybe I'm missing some flag when I do start qemu-system-arm?

Thanks in advance for help and hints.

-- 
Best regards,

Ɓukasz Majewski


pgpvwrDDsaHaf.pgp
Description: OpenPGP digital signature


Re: TPM Module

2021-09-13 Thread ToddAndMargo

On 9/13/21 4:25 AM, ToddAndMargo wrote:

Hi All,

Fedora 34
qemu-kvm-5.2.0-8.fc34.x86_64

I need a TPM module for Windows 11

Many thanks,
-T



Found it in the virtual machine manager.  It
was right under my nose!



Re: qemu-qvm: need an 8th gen CPU

2021-09-13 Thread ToddAndMargo

On 9/13/21 2:53 AM, ToddAndMargo wrote:

Hi All,

I need an 8th gen CPU to get Windows 11 to upgrade properly.
Which one of qemu-kvm's cpu's is 8th gen?

Many thanks,
-T




Ooops, forgot

Fedora 34
qemu-kvm-5.2.0-8.fc34.x86_64



TPM Module

2021-09-13 Thread ToddAndMargo

Hi All,

Fedora 34
qemu-kvm-5.2.0-8.fc34.x86_64

I need a TPM module for Windows 11

Many thanks,
-T



qemu-qvm: need an 8th gen CPU

2021-09-13 Thread ToddAndMargo

Hi All,

I need an 8th gen CPU to get Windows 11 to upgrade properly.
Which one of qemu-kvm's cpu's is 8th gen?

Many thanks,
-T


--

A computer without Microsoft is like
a chocolate cake without the mustard