KVM tells me on -help:
-d item1,... enable logging of specified items (use '-d help' for a list of log items)
-D logfile output log to logfile (default stderr)
I used it:
kvm -d in_asm,int -D mylog.log -boot d -cdrom myiso.iso -m 4069 -smp 4 -serial file:serial.log
Using qemu-system-x86_64 instead of kvm, everything is right, all output will be logged. But on enabling kvm (using -enable-kvm flag or command kvm), the file will be truncated but nothing logged.
Related
I'm following this guide to run multiple VMs on mac os with apple m1.
I got the following error:
sudo virt-install \
--name host1 \
--memory 2048 \
--vcpus 2 \
--disk size=30 \
--cdrom ./box.img \
--os-variant ubuntu22.04 \
--virt-type hvf \
--qemu-commandline='-M highmem=off -netdev vmnet-shared,id=net0 -device virtio-net-device,netdev=net0,mac=54:54:00:55:54:51' \
--network user
Password:
WARNING CDROM media does not print to the text console by default, so you likely will not see text install output. You might want to use --location. See the man page for examples of using --location with CDROM media
Starting install...
Allocating 'host1.qcow2' | 0 B 00:00:00 ...
Removing disk 'host1.qcow2' | 0 B 00:00:00
ERROR Failed to connect socket to '/opt/homebrew/var/run/libvirt/virtlogd-sock': No such file or directory
Domain installation does not appear to have been successful.
If it was, you can restart your domain by running:
virsh --connect qemu:///system start host1
otherwise, please restart your installation.
apparently it's not there:
$ ls -al /opt/homebrew/var/run/libvirt/virtlogd-sock
ls: /opt/homebrew/var/run/libvirt/virtlogd-sock: No such file or directory
but libvirt is up and running:
$ brew services list 130
Name Status User File
libvirt started root ~/Library/LaunchAgents/homebrew.mxcl.libvirt.plist
Im trying to use the -device,loader option in qemu. Originally, I wanted to load a file into memory, but that was (and still isnt) working. So, I tried to load a constant value into memory. This is my command:
qemu-system-aarch64 \
-machine virt \
-cpu cortex-a57 \
-smp 1 \
-m 3G \
-device loader,addr=0x14680000,data=0xdeadbeef,data-len=0x4\
-machine gic-version=3 \
-machine secure=true \
-machine virtualization=true \
-nographic \
-S -s
I then open gdb, and do:
target remote :1234
x/x 0x14680000
The result is not 0xdeadbeef, as I had expected, but 0xffffffff.
Why is this happening? I cant find much documentation on the loader device in qemu, and have mostly just been following:
https://qemu-project.gitlab.io/qemu/system/generic-loader.html
I'm working with VxWorks, a Real Time Operating System for embedded systems. They recently added QEMU support, and I've been trying to figure it out. (I'm fairly new to all these technologies.) I would like to checkpoint and restart the virtual machine, ie save the RAM and processor state and reload it later from exactly that point.
QEMU has some support for this called "snapshots." However, everything I've seen and tried requires a disk image in qcow2 format. But my simulation has no disk, the program is loaded directly into RAM and run.
Here's my QEMU command:
qemu-system-aarch64 -m 4096M -smp 4 -machnie xlnx-zcu102 -device loader,file=~/vxworks_21.03/workspace3/QEMU_helloWorld/default/vxWorks,addr=0x00100000 -nographic -monitor telnet:127.0.0.1:35163,server,nowait -serial telnet:127.0.0.1:39251,server -device loader,file=~/vxworks_21.03/workspace3/vip_xlnx_zynqmp_smp_64/default/xlnx-zcu102-rev-1.1.dtb,addr=0x0f000000 -device loader,addr=0x000ffffc,data=0xd2a1e000,data-len=4 -device loader,addr=0x000ffffc,cpu-num=0 -nic user -nic user -nic user -nic user,id=n0,hostfwd=tcp:127.0.0.1:0-:1534,hostfwd=udp:127.0.0.1:0-:17185
Then I log into the monitor and:
$ telnet 127.0.0.1 35163
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
QEMU 5.2.0 monitor - type 'help' for more information
(qemu) savevm
Error: No block device can accept snapshots
I tried a number of things, like creating an empty disk image, or the snapshot_blkdev command, but no luck so far.
The host is RedHat Linux 8.4 running on an x86 desktop, the guest is ARM64.
It turns out that a disk image is required to do snapshots, but you don't have to hook it up to the guest. To do that you pass qemu -drive argument with with if=none. Like this:
-drive if=none,format=qcow2,file=dummy.qcow2
So here is the whole sequence that worked:
$ qemu-img create -f qcow2 dummy.qcow2 32M
$ qemu-system-aarch64 -m 4096M -smp 4 -machnie xlnx-zcu102 -device loader,file=vxWorks,addr=0x00100000 -nographic -monitor telnet:127.0.0.1:35163,server,nowait -serial telnet:127.0.0.1:39251,server -device loader,file=xlnx-zcu102-rev-1.1.dtb,addr=0x0f000000 -device loader,addr=0x000ffffc,data=0xd2a1e000,data-len=4 -device loader,addr=0x000ffffc,cpu-num=0 -nic user -nic user -nic user -nic user,id=n0,hostfwd=tcp:127.0.0.1:0-:1534,hostfwd=udp:127.0.0.1:0-:17185 -snapshot -drive if=none,format=qcow2,file=dummy.qcow2
Then in the monitor terminal savevm and loadvm work:
$ telnet 127.0.0.1 35163
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
QEMU 5.2.0 monitor - type 'help' for more information
(qemu) savevm save1
(qemu) info snapshots
List of snapshots present on all disks:
ID TAG VM SIZE DATE VM CLOCK ICOUNT
-- save1 44.3 MiB 2021-06-28 10:08:28 00:00:05.952
(qemu) loadvm save1
This information came thanks to Peter Maydell and his blog post: https://translatedcode.wordpress.com/2015/07/06/tricks-for-debugging-qemu-savevm-snapshots/
Background:
Host: Win10
Qemu: Qemu 6.0.0
This is my command: qemu-system-arm.exe -D ./log.txt -M sabrelite -smp 4 -m 1G -nographic -serial null -serial mon:stdio -kernel image -dtb sabrelite.dtb
I'm using this command to create a Qemu, in order to run some tests with a lot of output logs on it.
I wanna save the outputs to a file.
Question:
How can I save the console output from windows host QEMU to a file?
It seems that the -D ./log.txt just created an empty file, and did not save the outputs to it.
The -D option is for the log file for the debug info enabled with '-d'. If you don't specify any '-d' options there will be no debug info in the log file.
The output of the serial console is entirely separate. That is controlled by the '-serial' option, which currently you have set up to go to stdio (with a monitor muxed to also use stdio). You can look at the other options for where -serial can be directed; this does include a "send to file", but note that if you just do that then you won't also be able to see it on the console and you won't be able to input anything.
You can use standard windows output redirection. This command line will redirect stdout and stderr to log.txt:
qemu-system-arm.exe -M sabrelite -smp 4 -m 1G -nographic -serial null -serial mon:stdio -kernel image -dtb sabrelite.dtb > 1> ./log.txt 2>&1
I have a simple pcap with some web traffic and am using tshark to obtain some header information from it:
I use the following command:
tshark -r ./capture-1-5 -Y "http2" -o tls.keylog_file:ssl-key.log \
-T fields -e frame.number -e _ws.col.Time -e ip.src -e tcp.srcport \
-e ip.dst -e tcp.dstport -e _ws.col.Protocol -e frame.len \
-e _ws.col.Info -E header=y -E separator="," -E quote=d \
-E occurrence=f > desegmented.csv
I realized that in this case all fragments are reassembled resulting in huge packets. However, I do not want reassembled packets. So, I add an extra option to tshark:
tshark -r ./capture-1-5 -Y "http2" -o tls.keylog_file:ssl-key.log \
-T fields -e frame.number -e _ws.col.Time -e ip.src -e tcp.srcport \
-e ip.dst -e tcp.dstport -e _ws.col.Protocol -e frame.len \
-e _ws.col.Info -E header=y -E separator="," -E quote=d \
-E occurrence=f -o tcp.desegment_tcp_streams:FALSE > segmented.csv
My intuition is that the resultant disassembled.csv file should be greater in size and should contain more rows given that the "packets above the MTU" will be shown as more than one packet.
However, I observe the opposite. The resultant file without assembly is smaller and has almost halved the number of rows.
-rw-r--r-- 1 root root 210K May 18 18:21 desegmented.csv
-rw-r--r-- 1 root root 97K May 18 18:21 segmented.csv
# cat desegmented.csv |wc -l
2635
# cat segmented.csv |wc -l
1233
Is this a normal behavior? I don't see (manually) where the packets start to disappear (and why) or see any pattern because of the two-way communication (missing packets here and there).
I assume that maybe, in the disassebmled.csv case, every packet or even the whole packet stream that resulted in at least one packet above the MTU is completely dropped.
I tried to also apply ip.defragment:FALSE but still the same results.
Thanks
For reproducing, the files can be downloaded from here
Thanks, #JimD., I have already come to a similar conclusion!
Packet capture itself has to be segmented to do this precisely.
So, tried to go one layer below, and make the packet capture itself to be segmented via
ethtool -K eth0 gso off tso off gro off sg off tx off rx off
(just to make sure).
The problem is that packet capturing is done in a docker container, so at multiple places, I have to issue this command to be fully working.
These places include the docker0 bridge, eth0 inside the container and the corresponding vethXXXXXX on the host, from which the second requires privileged containers that pose further issues :)