On my Dom0, I have some guests running. For each of them, I can see a qemu process:
# ps -eaf | grep qemu
root 8936 3879 0 Sep13 ? 00:12:42 /usr/lib/xen/bin/qemu-dm -d 419 -serial pty -domain-name my_pv_huest -videoram 4 -vnc 0.0.0.0:0 -vncunused -M xenpv
root 18117 3879 0 Sep18 ? 00:10:00 /usr/lib/xen/bin/qemu-dm -d 430 -domain-name my_pvhvm_guest -videoram 4 -k en-us -vnc 0.0.0.0:0 -vncunused -vcpus 2 -vcpu_avail 0x3 -boot c -serial pty -acpi -net none -M xenfv
root 31709 3879 0 Sep18 ? 00:09:37 /usr/lib/xen/bin/qemu-dm -d 429 -domain-name my_hvm_guest -videoram 4 -k en-us -vnc 0.0.0.0:0 -vncunused -vcpus 1 -vcpu_avail 0x1 -boot c -serial pty -acpi -net nic,vlan=1,macaddr=00:16:3e:40:94:4f,model=rtl8139 -net tap,vlan=1,ifname=tap429.0,bridge=br0 -M xenfv
The first, second and third lines of output correspond to pvm, pvhvm and hvm guests, respectively.
These are my questions:
As far as I know , use of qemu-dm tool is only for the access of network and disk for HVM guests as it will not have front end drivers. Then why PVM runs as qemu-dm? Or is the process just named as qemu-dm and not related to what qemu-dm really does?
From where can I get more info about these running processes, at least how to understand the detailed meaning of the process information and options?
QEMU is used for surprising things e.g. running VNC server, providing I/O when you use files for VM filesystems.
When you don't run any guest VMs you will still have QEMU for dom0.
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
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/
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.
I've installed Orion Context Broker 0.23.0 and it behaves rare: it only works half of the times. For instance, when trying to retrieve the version I get this error message:
$ curl "http://localhost:1026/version"
curl: (52) Empty reply from server
$ curl "http://localhost:1026/version"
<orion>
<version>0.23.0</version>
<uptime>15 d, 22 h, 13 m, 18 s</uptime>
<git_hash>f5d76a6f11736d52402e63a4aa0ba990bff7f5eb</git_hash>
<compile_time>Fri Jul 10 13:21:42 CEST 2015</compile_time>
<compiled_by>fermin</compiled_by>
<compiled_in>centollo</compiled_in>
</orion>
$ curl "http://localhost:1026/version"
curl: (52) Empty reply from server
$ curl "http://localhost:1026/version"
<orion>
<version>0.23.0</version>
<uptime>15 d, 22 h, 13 m, 53 s</uptime>
<git_hash>f5d76a6f11736d52402e63a4aa0ba990bff7f5eb</git_hash>
<compile_time>Fri Jul 10 13:21:42 CEST 2015</compile_time>
<compiled_by>fermin</compiled_by>
<compiled_in>centollo</compiled_in>
</orion>
This behaviour is deterministic, I mean, after failing it always works, and after working it always fails. This occurs with all the operations within the REST API.
I've checked the listening ports and the process running them matches the Orion's one:
$ sudo netstat -ntlp | grep 1026
tcp 0 0 0.0.0.0:1026 0.0.0.0:* LISTEN 9944/contextBroker
tcp 0 0 :::1026 :::* LISTEN 9944/contextBroker
$ ps ax | grep contextBroker | grep -v grep
9944 ? Ssl 0:13 /usr/bin/contextBroker -port 1026 -logDir /var/log/contextBroker -pidpath /var/run/contextBroker/contextBroker.pid -dbhost localhost -db orion -multiservice
Any hints? Thanks!
Orion runs by default listening to IPv4 and IPv6. We have found that in cases similar to the ones you described disabling IPv6 solves the problem (we don't know yet the exact cause, maybe is related with the operating system or it is involved is some way...).
Tu run Orion in only-IPv4 mode you have to use the -ipv4 option either in the contextBroker command line or (if you are running Orion as a service) editing the /etc/sysconfig/contextBroker file to add -ipv4 to the BROKER_EXTRA_OPS variable (have a look to the documentation for more information about configuring Orion as a service). After modifying /etc/sysconfig/contextBroker you have to restart Orion using:
sudo /etc/init.d/contextBroker restart
Using linux KVM/QEMU, I have a virtual machine with two NICs presented at the host as tap interfaces:
-net nic,macaddr=AA:AA:AA:AA:00:01,model=virtio \
-net tap,ifname=tap0a,script=ifupbr0.sh \
-net nic,macaddr=AA:AA:AA:AA:00:02,model=virtio \
-net tap,ifname=tap0b,script=ifupbr1.sh \
In the guest (also running linux), these are configured with different subnets:
eth0 Link encap:Ethernet HWaddr aa:aa:aa:aa:00:01
inet addr:10.0.0.10 Bcast:10.0.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth1 Link encap:Ethernet HWaddr aa:aa:aa:aa:00:02
inet addr:192.168.0.10 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Routes only go to the expected places:
ip route list
default via 10.0.0.1 dev eth0 metric 100
10.0.0.0/16 dev eth0 proto kernel scope link src 10.0.0.10
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.10
But somehow don't seem to be treated by KVM as being connected to distinct networks.
If I trace the individual interfaces, they both see the same traffic.
For example, if I ping on the 10.0.0.0/16 subnet, ping -I eth0 10.0.0.1
And simultaneously trace the two tap interfaces with tcpdump , I see the pings coming through on both tap interfaces:
sudo tcpdump -n -i tap0a
10:51:56.308190 IP 10.0.0.10 > 10.0.0.1: ICMP echo request, id 867, seq 1, length 64
10:51:56.308217 IP 10.0.0.1 > 10.0.0.10: ICMP echo reply, id 867, seq 1, length 64
sudo tcpdump -n -i tap0b
10:51:56.308190 IP 10.0.0.10 > 10.0.0.1: ICMP echo request, id 867, seq 1, length 64
10:51:56.308217 IP 10.0.0.1 > 10.0.0.10: ICMP echo reply, id 867, seq 1, length 64
That seems strange to me since it's pretty clear that the guest OS would have only actually sent this on the tap0a interface.
Is this expected behavior? Is there a way to keep the interfaces separate as I expected?
Is this some misconfiguration issue on my part?
Additional info, here are the two ifupbr0.sh and ifupbr1.sh scripts:
% cat ifupbr1.sh
#!/bin/sh
set -x
switch=br0
echo args = $*
if [ -n "$1" ];then
sudo tunctl -u `whoami` -t $1
sudo ip link set $1 up
sleep 0.5s
sudo brctl addif $switch $1
exit 0
else
echo "Error: no interface specified"
exit 1
fi
% cat ifupbr1.sh
#!/bin/sh
set -x
switch=br1
echo args = $*
if [ -n "$1" ];then
sudo tunctl -u `whoami` -t $1
sudo ip link set $1 up
sleep 0.5s
sudo brctl addif $switch $1
exit 0
else
echo "Error: no interface specified"
exit 1
fi
I see this problem even if I detach the "tap0b" interface from the br1. It still shows the traffic that I'd expect only for tap0a. That is, even when:
% brctl show
bridge name bridge id STP enabled interfaces
br0 8000.26a2d168234b no tap0a
br1 8000.000000000000 no
br2 8000.000000000000 no
It looks like I answered my own question eventually, but I'll document it for anyone else that hits this.
Evidently this really is the intended behavior of KVM for the options I was using.
At this URL:
http://wiki.qemu.org/Documentation/Networking
I found:
QEMU previously used the -net nic option instead of -device DEVNAME
and -net TYPE instead of -netdev TYPE. This is considered obsolete
since QEMU 0.12, although it continues to work.
The legacy syntax to create virtual network devices is:
-net nic,model=MODEL
And sure enough, I'm using this legacy syntax. I thought the new syntax was just more flexible but it apparently actually has this intended behavior:
The obsolete -net syntax automatically created an emulated hub (called
a QEMU "VLAN", for virtual LAN) that forwards traffic from any device
connected to it to every other device on the "VLAN". It is not an
802.1q VLAN, just an isolated network segment.
The vlans it supports are also just emulated hubs, and don't forward out to the host at all as best I can tell.
Regardless, I reworked the QEMU options to use the "new" netdev syntax and obtained the behavior I wanted here.
What do you have in the ifupbr0.sh and ifupbr1.sh scripts? What bridging tool are you using? That is the important piece which segregates your traffic to the interfaces desired.
I've used openvswitch to handle my bridging stuff. But before that I used bridge-utils in Debian.
I wrote some information about bridge-utils at http://blog.raymond.burkholder.net/index.php?/archives/31-QEMUKVM-BridgeTap-Network-Configuration.html. I have other posts regarding what I did with bridging on the OpenVSwitch side of things.