#StackBounty: #virtual-machine #kvm #qemu #virt-manager How to create snapshot with UEFI firmware on virt-manager?

Bounty: 500

I am using qemu v2.11.1 and libvirt 4.0.0 – both are latest stable for Ubuntu 18.04. The guest is Windows 10 running on Tianocore UEFI firmware. When I tried to take a snapshot on virt-manager, it thew an error and looks like it does not allow internal snapshots to be created on UEFI firmware.

enter image description here

I do not really concern about having a chain of external snapshots, as long as I can use UEFI firmware. However, virt-manager shows no option to choose between internal and external snapshot styles in the snapshot management tab.

Is there any way to do that? Or I must give up on virt-manager go back to command line?


Get this bounty!!!

#StackBounty: #bash #permissions #kvm #qemu #libvirt Clean way of running virt-install with an iso file that's in your home directo…

Bounty: 50

I have a script that automatically creates and runs a VM. That script is used by many people. You basically call the script giving it some information like what PCI or USB devices you want to pass through and which iso to use to install the OS and then the script runs sudo qemu-system-x86_64 with the appropriate parameters.

So if you break it down, you could currently call my script like this:

./create-vm.sh /home/me/os-images/windows10.iso

And this works fine.

But now I want to take it a step further and use sudo virt-install ... instead of sudo qemu-system-x86_64 ... and that is causing major issues because with virt-install it can’t access the iso file anymore. Presumably because it drops its root privileges and uses the qemu user even if I run it with sudo…

So now I have to make a difficult decision:

  • Do I move the iso file to /var/lib/libvirt/images? (No because the user might need that file in the exact location where it is right now.)
  • Do I copy the iso to /var/lib/libvirt/images? (No because the user might not have enough disk space and it just seems like a waste of resources.)
  • Do I set user = root or user = me in /etc/libvirt/qemu.conf? (No, because that is a global setting that might mess up other qemu stuff the user is doing. – I have tried it though and it causes libvirtd.service to crash.)
  • Do I add the group of the iso file to the qemu user? (No, because that could have unwanted side effects, potentially giving qemu more access in situations where the user wouldn’t want it. – Nevertheless, I’ve tried it and it didn’t work, presumably some SElinux magic is blocking it…)
  • Do I change the owner of the iso file to qemu? (No, because that might have unwanted side effects. – Besides that, when I try it I still get permission denied errors, probably because of SElinux.)
  • Do I mount the iso and make the mountpoint available to the qemu user? (No, because iso files can be very complex and some data will not be available in the mountpoint.)
  • Do I mount the folder containing the iso? (No because the iso file would still have the same owner/group.)

I just can’t seem to find a good solution. What am I supposed to do now? I really need some of the functionality that virt-install offers over qemu-system-x86_64.

Note: In reality there is not just one iso image, but also a floppy image, some other iso files containing drivers and an ACPI table file. I get permission errors for all of these files from virt-install.


Get this bounty!!!

#StackBounty: #bash #permissions #kvm #qemu #libvirt Clean way of running virt-install with an iso file that's in your home directo…

Bounty: 50

I have a script that automatically creates and runs a VM. That script is used by many people. You basically call the script giving it some information like what PCI or USB devices you want to pass through and which iso to use to install the OS and then the script runs sudo qemu-system-x86_64 with the appropriate parameters.

So if you break it down, you could currently call my script like this:

./create-vm.sh /home/me/os-images/windows10.iso

And this works fine.

But now I want to take it a step further and use sudo virt-install ... instead of sudo qemu-system-x86_64 ... and that is causing major issues because with virt-install it can’t access the iso file anymore. Presumably because it drops its root privileges and uses the qemu user even if I run it with sudo…

So now I have to make a difficult decision:

  • Do I move the iso file to /var/lib/libvirt/images? (No because the user might need that file in the exact location where it is right now.)
  • Do I copy the iso to /var/lib/libvirt/images? (No because the user might not have enough disk space and it just seems like a waste of resources.)
  • Do I set user = root or user = me in /etc/libvirt/qemu.conf? (No, because that is a global setting that might mess up other qemu stuff the user is doing. – I have tried it though and it causes libvirtd.service to crash.)
  • Do I add the group of the iso file to the qemu user? (No, because that could have unwanted side effects, potentially giving qemu more access in situations where the user wouldn’t want it. – Nevertheless, I’ve tried it and it didn’t work, presumably some SElinux magic is blocking it…)
  • Do I change the owner of the iso file to qemu? (No, because that might have unwanted side effects. – Besides that, when I try it I still get permission denied errors, probably because of SElinux.)
  • Do I mount the iso and make the mountpoint available to the qemu user? (No, because iso files can be very complex and some data will not be available in the mountpoint.)
  • Do I mount the folder containing the iso? (No because the iso file would still have the same owner/group.)

I just can’t seem to find a good solution. What am I supposed to do now? I really need some of the functionality that virt-install offers over qemu-system-x86_64.

Note: In reality there is not just one iso image, but also a floppy image, some other iso files containing drivers and an ACPI table file. I get permission errors for all of these files from virt-install.


Get this bounty!!!

#StackBounty: #bash #permissions #kvm #qemu #libvirt Clean way of running virt-install with an iso file that's in your home directo…

Bounty: 50

I have a script that automatically creates and runs a VM. That script is used by many people. You basically call the script giving it some information like what PCI or USB devices you want to pass through and which iso to use to install the OS and then the script runs sudo qemu-system-x86_64 with the appropriate parameters.

So if you break it down, you could currently call my script like this:

./create-vm.sh /home/me/os-images/windows10.iso

And this works fine.

But now I want to take it a step further and use sudo virt-install ... instead of sudo qemu-system-x86_64 ... and that is causing major issues because with virt-install it can’t access the iso file anymore. Presumably because it drops its root privileges and uses the qemu user even if I run it with sudo…

So now I have to make a difficult decision:

  • Do I move the iso file to /var/lib/libvirt/images? (No because the user might need that file in the exact location where it is right now.)
  • Do I copy the iso to /var/lib/libvirt/images? (No because the user might not have enough disk space and it just seems like a waste of resources.)
  • Do I set user = root or user = me in /etc/libvirt/qemu.conf? (No, because that is a global setting that might mess up other qemu stuff the user is doing. – I have tried it though and it causes libvirtd.service to crash.)
  • Do I add the group of the iso file to the qemu user? (No, because that could have unwanted side effects, potentially giving qemu more access in situations where the user wouldn’t want it. – Nevertheless, I’ve tried it and it didn’t work, presumably some SElinux magic is blocking it…)
  • Do I change the owner of the iso file to qemu? (No, because that might have unwanted side effects. – Besides that, when I try it I still get permission denied errors, probably because of SElinux.)
  • Do I mount the iso and make the mountpoint available to the qemu user? (No, because iso files can be very complex and some data will not be available in the mountpoint.)
  • Do I mount the folder containing the iso? (No because the iso file would still have the same owner/group.)

I just can’t seem to find a good solution. What am I supposed to do now? I really need some of the functionality that virt-install offers over qemu-system-x86_64.

Note: In reality there is not just one iso image, but also a floppy image, some other iso files containing drivers and an ACPI table file. I get permission errors for all of these files from virt-install.


Get this bounty!!!

#StackBounty: #graphics #virtualization #kvm #opengl #virt-manager How to use OpenGL/3D acceleration in virt-manager with ubuntu?

Bounty: 100

Currently on Ubuntu 20.04 both as host and guest, I followed http://ryan.himmelwright.net/post/virtio-3d-vms/ and activated 3D acceleration on video, and OpenGL on dsplay, but on VM launch I get

SPICE GL support is local only for now and incompatible with -spice port/tls-port

How can I make it work?

UPDATE:

I disabled Listen Type to None

like thisenter image description here

but I get a very glitchy image:

enter image description here


Get this bounty!!!

#StackBounty: #networking #20.04 #kvm #qemu Bridged networking in KVM/Qemu LAN addressed packets dropped

Bounty: 100

Summary: In a bridged KVM/QEMU configuration, network packets destined to guest VM do not get there.

Configuration: The host is an up to date Ubuntu 20.04.2 LTS server; The guest is any of 3 VMs, a very old 16.04 Ubuntu server, an old Ubuntu 20.04 desktop, and a brand new Ubuntu 21.04 desktop. The first 2 VMs are being converted from non-bridged, NAT’d, and the 3rd was created specifying bridged networking. Ultimately the VMs will get their IP addresses from the main LAN, via DHCP, but for now and for better debugging information, they are using static IP addresses.

The host bridge definition, /etc/netplan/01-netcfg.yaml, (this is one of many many attempts):

# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      dhcp4: no
  bridges:
    br0:
#      interfaces: [ enp3s0 ]
      dhcp4: yes
#      dhcp6: no
#      link-local: [ ]
      interfaces:
        - enp3s0
#      parameters:
#        stp: true
#        forward-delay: 4

The virtual stuff, /etc/libvirt/qemu/networks/br0.xml:

<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
  virsh net-edit br0
or other application using the libvirt API.
-->

<network>
  <name>br0</name>
  <uuid>40a8752c-d074-4802-bae8-b0aef95d9c99</uuid>
  <forward mode='bridge'/>
  <bridge name='br0'/>
</network>

Notes: many versions of bridge .xml files have been tried, including different names, and different references use differing techniques. The Ubuntu Serverguide references this which says the name and bridge name have to be the same, but other references do not have them the same. Once the bare file has been created with nano, these commands:

virsh net-define br0.xml
virsh net-autostart br0
virsh net-start br0

were used to add and configure it. The default, NAT’d way was unlinked, from the autostart directory, so as not to. Eventually, it was undefined. The result:

$ virsh net-list --all
 Name      State      Autostart   Persistent
----------------------------------------------
 br0       active     yes         yes

At this point, there are no iptables rules at all after re-boot. However the VMs do not have network access. Note that some references mention special iptables rules and special attributes for the br_netfilter module, all of which have been tried. This question is already long enough without going into all the detail of variations tried here.

Debug Details: No matter the configuration variant, the base issue is always the same, VM destined packets do not seem to arrive at the host, at least as seen by tcpdump. However, broadcast type packets do arrive and do get to the client VM.

This example will use 192.168.111.59 (MAC: 52:54:00:60:ea:0e), the 16.04 server VM, and 192.168.111.132, a raspberry-pi, on the LAN. The 20.04 host server is at 192.168.111.136. The netmask is 24 bits, 255.255.255.0. The gateway and DHCP server is a Debian server (on which bridged guest VMs work fine, by the way).

First tpcudmp as seen from the raspberry-pi during ping:

doug@rpi2:~ $ sudo tcpdump -n -tttt -i eth0 ether host 52:54:00:60:ea:0e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
2021-04-23 08:33:19.363553 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 08:33:19.487239 IP 192.168.111.132 > 192.168.111.59: ICMP echo request, id 27848, seq 14, length 64
2021-04-23 08:33:20.363542 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 08:33:20.527250 IP 192.168.111.132 > 192.168.111.59: ICMP echo request, id 27848, seq 15, length 64
2021-04-23 08:33:21.567215 IP 192.168.111.132 > 192.168.111.59: ICMP echo request, id 27848, seq 16, length 64
2021-04-23 08:33:22.607228 IP 192.168.111.132 > 192.168.111.59: ICMP echo request, id 27848, seq 17, length 64
2021-04-23 08:33:23.372351 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 08:33:23.647228 IP 192.168.111.132 > 192.168.111.59: ICMP echo request, id 27848, seq 18, length 64
2021-04-23 08:33:24.371431 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 46

Observe the VM is sending out packets just fine, as seen via all the ARP activity. However it never replies to anything. Now lets watch the same activity from the host, noting tcpdump output is the same for any of interfaces br0 or enp3s0 or vnet0.

$ sudo tcpdump -n -tttt -i br0 ether host 52:54:00:60:ea:0e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
2021-04-23 08:40:38.837608 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:39.837159 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:40.837122 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:43.842985 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:44.840895 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:45.840991 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:48.848508 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:49.848895 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:50.848871 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:51.514011 ARP, Reply 192.168.111.59 is-at 52:54:00:60:ea:0e, length 28
2021-04-23 08:40:52.928400 ARP, Reply 192.168.111.59 is-at 52:54:00:60:ea:0e, length 28
2021-04-23 08:40:53.853881 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:54.852472 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28

Observe every so often the VM does respond, but later on we’ll see that it is to a broadcast packet. It also seems as though a problem is that 192.168.111.1 isn’t responding. It is, and for whatever reason, that packets are not seen here at the tcpdump level. Also notice no ICMP packets from the raspberry-pi. Now, show the gateway responding (this is "br0" on a different computer. EDIT: replaced with a better capture example, hence the different timestamps):

$ sudo tcpdump -n -tttt -e -i br0 ether host 52:54:00:60:ea:0e
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
2021-04-23 22:25:17.434415 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 22:25:17.434432 xx:xx:xx:xx:xx:xx > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at xx:xx:xx:xx:xx:xx, length 28
2021-04-23 22:25:20.440843 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 22:25:20.440859 xx:xx:xx:xx:xx:xx > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at xx:xx:xx:xx:xx:xx, length 28
2021-04-23 22:25:21.438316 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 22:25:21.438332 xx:xx:xx:xx:xx:xx > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at xx:xx:xx:xx:xx:xx, length 28
2021-04-23 22:25:22.438266 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 22:25:22.438283 xx:xx:xx:xx:xx:xx > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at xx:xx:xx:xx:xx:xx, length 28
2021-04-23 22:25:25.446312 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 22:25:25.446329 xx:xx:xx:xx:xx:xx > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at xx:xx:xx:xx:xx:xx, length 28
2021-04-23 22:25:26.446195 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 22:25:26.446211 xx:xx:xx:xx:xx:xx > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at xx:xx:xx:xx:xx:xx, length 28

Observe the VM outgoing packets, and ARP does complete. I can’t figure out how to copy and paste from the VM, which I communicate with via VNC, but it shows some completed, but stale ARP entries in response to the ip neigh command and tcpdump shows some ARP and broadcast packets from the LAN.

Other information (MACs not relevant to this question have been hidden):

$ brctl show br0
bridge name     bridge id               STP enabled     interfaces
br0             8000.3c7c3f0d9983       no              enp3s0
                                                        vnet0
$ brctl showmacs br0
port no mac addr                is local?       ageing timer
  1     xx:xx:xx:xx:xx:xx       no                 0.00
  1     3c:7c:3f:0d:99:83       yes                0.00
  1     3c:7c:3f:0d:99:83       yes                0.00
  2     52:54:00:60:ea:0e       no                 1.68
  1     xx:xx:xx:xx:xx:xx       no                 2.14
  1     xx:xx:xx:xx:xx:xx       no                36.84
  1     xx:xx:xx:xx:xx:xx       no                89.57
  1     xx:xx:xx:xx:xx:xx       no               226.51
  1     xx:xx:xx:xx:xx:xx       no                13.28
  1     xx:xx:xx:xx:xx:xx       no               165.68
  1     xx:xx:xx:xx:xx:xx       no               165.68
  1     xx:xx:xx:xx:xx:xx       no               265.02
  1     xx:xx:xx:xx:xx:xx       no                27.62
  2     fe:54:00:60:ea:0e       yes                0.00
  2     fe:54:00:60:ea:0e       yes                0.00

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
    link/ether 3c:7c:3f:0d:99:83 brd ff:ff:ff:ff:ff:ff
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 3c:7c:3f:0d:99:83 brd ff:ff:ff:ff:ff:ff
    inet 192.168.111.136/24 brd 192.168.111.255 scope global dynamic br0
       valid_lft 51547sec preferred_lft 51547sec
7: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:60:ea:0e brd ff:ff:ff:ff:ff:ff

EDIT: interestingly, all ARP packets from my D-Link AC2600 Wi-Fi Gigabit Router, configured as a switch, always appear on the host and get to the VM and are replied to:

$ sudo tcpdump -n -tttt -e -i br0 ether host aa:aa:aa:aa:aa:aa
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
2021-04-23 22:45:51.463524 aa:aa:aa:aa:aa:aa > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.59 (ff:ff:ff:ff:ff:ff) tell 192.168.111.58, length 46
2021-04-23 22:45:51.463631 52:54:00:60:ea:0e > aa:aa:aa:aa:aa:aa, ethertype ARP (0x0806), length 42: Reply 192.168.111.59 is-at 52:54:00:60:ea:0e, length 28
2021-04-23 22:46:51.466955 aa:aa:aa:aa:aa:aa > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.59 (ff:ff:ff:ff:ff:ff) tell 192.168.111.58, length 46
2021-04-23 22:46:51.467030 52:54:00:60:ea:0e > aa:aa:aa:aa:aa:aa, ethertype ARP (0x0806), length 42: Reply 192.168.111.59 is-at 52:54:00:60:ea:0e, length 28
2021-04-23 22:47:51.466889 aa:aa:aa:aa:aa:aa > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.59 (ff:ff:ff:ff:ff:ff) tell 192.168.111.58, length 46
2021-04-23 22:47:51.466965 52:54:00:60:ea:0e > aa:aa:aa:aa:aa:aa, ethertype ARP (0x0806), length 42: Reply 192.168.111.59 is-at 52:54:00:60:ea:0e, length 28
2021-04-23 22:48:51.479096 aa:aa:aa:aa:aa:aa > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.59 (ff:ff:ff:ff:ff:ff) tell 192.168.111.58, length 46
2021-04-23 22:48:51.479178 52:54:00:60:ea:0e > aa:aa:aa:aa:aa:aa, ethertype ARP (0x0806), length 42: Reply 192.168.111.59 is-at 52:54:00:60:ea:0e, length 28

EDIT 3 – New configuration test: In an attempt to reduce the number of variables the following was done:

  • An about to be retired Ubuntu 16.04 server was powered up, providing a new isolated LAN.
  • the host Ubuntu 20.04 server was connected directly to the LAN side NIC of the 16.04 server. No switches were involved at all, just one long Ethernet cable.
  • Things were tested, and seemed to work fine. Access to everything was via ssh from my main LAN out through my main static WAN IP and back in via my test WAN static IP to the old 16.04 server. Then a chained ssh session from there to the 20.04 host server.
  • The Ubuntu 16.04 VM client was started on the host.
  • "ping" was attempted from the old 16.04 gateway server to the client.
  • The results were the same as the original configuration.

tcpdump on gateway old 16.04 server:

doug@DOUG-64:~$ sudo tcpdump -n -tttt -e -i enp2s0 ether host 52:54:00:60:ea:0e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
2021-04-26 15:10:00.701941 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-26 15:10:00.701965 00:19:b9:0d:af:fa > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at 00:19:b9:0d:af:fa, length 28
2021-04-26 15:10:01.699156 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-26 15:10:01.699169 00:19:b9:0d:af:fa > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at 00:19:b9:0d:af:fa, length 28
2021-04-26 15:10:02.699141 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-26 15:10:02.699154 00:19:b9:0d:af:fa > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at 00:19:b9:0d:af:fa, length 28
2021-04-26 15:10:05.707404 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-26 15:10:05.707417 00:19:b9:0d:af:fa > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at 00:19:b9:0d:af:fa, length 28
2021-04-26 15:10:06.707097 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-26 15:10:06.707110 00:19:b9:0d:af:fa > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at 00:19:b9:0d:af:fa, length 28
2021-04-26 15:10:07.707094 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-26 15:10:07.707107 00:19:b9:0d:af:fa > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at 00:19:b9:0d:af:fa, length 28

tcpdump on 20.04 host server:

doug@s19:~$ sudo tcpdump -n -tttt -e -i br0 ether host 52:54:00:60:ea:0e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
2021-04-26 15:11:35.801771 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:36.800497 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:37.800491 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:40.807062 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:41.804469 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:42.804444 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:45.812553 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:46.812405 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:47.812398 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28

As a side note: From my chained ssh session to the 20.04 host server, I can chain again and ssh to the VM client just fine.

Conclusion: Something is wrong right at the the Link Layer on the Ubuntu 20.04 server such that the incoming packets are not even "seen" by tcpdump, nor get to the VM guest. Diagram.

EDIT 4: Comparing to information provided by Christian Ehrhardt a potential difference is on my system is the br0 MAC list might be incorrect, with the fist byte replaced. Note: non relevant MAC deleted, 3 VMs running:

doug@s19:~$ brctl showmacs br0
port no mac addr                is local?       ageing timer
  1     3c:7c:3f:0d:99:83       yes                0.00  <<< enp3s0, br0
  1     3c:7c:3f:0d:99:83       yes                0.00  <<< enp3s0, br0
  4     52:54:00:22:2f:dc       no                 5.15  <<< VM 3
  2     52:54:00:60:ea:0e       no                 3.29  <<< VM 1
  3     52:54:00:60:ea:3e       no                12.67  <<< VM 2
  4     fe:54:00:22:2f:dc       yes                0.00  <<< vnet2
  4     fe:54:00:22:2f:dc       yes                0.00  <<< vnet2
  2     fe:54:00:60:ea:0e       yes                0.00  <<< vnet0
  2     fe:54:00:60:ea:0e       yes                0.00  <<< vnet0
  3     fe:54:00:60:ea:3e       yes                0.00  <<< vnet1
  3     fe:54:00:60:ea:3e       yes                0.00  <<< vnet1

Actually, now I realize the information from Christian is incomplete:

$ brctl showmacs br0
port no mac addr        is local?   ageing timer
  2 52:54:00:48:40:69   no         2.36   <- Guest
  1 52:54:00:95:e4:2a   no         0.00   <- outside system
  1 52:54:00:9b:9b:0e   yes        0.00   <- Host
  1 52:54:00:9b:9b:0e   yes        0.00   <- Host

EDIT 5: Similar data to EDIT 4, but from Debian Server with 2 VMs running, which is working properly:

doug@s15:~$ sudo brctl showmacs br0
port no mac addr                is local?       ageing timer
  1     52:54:00:22:2f:dc       no                17.85
  2     52:54:00:27:1b:5e       no                18.48  <<< VM 1
  3     52:54:00:27:1b:ae       no                 2.14  <<< VM 2
  1     f4:8c:eb:c8:08:a0       no                18.48
  2     fe:71:fa:75:16:93       yes                0.00  <<< tap0 (VM1)
  2     fe:71:fa:75:16:93       yes                0.00  <<< tap0
  3     fe:e1:c5:2a:c7:e3       yes                0.00  <<< tap1 (VM2)
  3     fe:e1:c5:2a:c7:e3       yes                0.00  <<< tap1

Question: What is wrong and how can I get bridged VMs working properly?


Get this bounty!!!

#StackBounty: #kvm #stty #pts screen /dev/pts/<num> of a VM never has correct stty settings

Bounty: 50

A virtual machine (using linux+kvm+qemu) is setup to provided a serial port for a terminal, which is made available via a pseudo-terminal, some random /dev/pts/<number>

I use screen as a way to interact with /dev/pts/<number>, as it has proven better than
cat /dev/pts/<number> & cat > /dev/pts/<number> which did not correctly handle escapes like ctrl-c, or echoed input multiple times.

The issue and core of this question is that the settings of the "tty/pts" as inquired via stty --all inside the shell wihtin screen /dev/pts/<number> does not have the correct settings with respect to the dimensinos (cols and rows) which effectively causes headache by incorrect line-wrapping etc inside the shell of the VM.

Since there is more than 1 machine and terminal/tty/pts at play here I am not experienced enought to understand how to setup the correct settings.

How can the screen /dev/pts/<number> shell be made aware of the correct stty settings?

** Update **

The output of stty --all within the shell of the vm is.

root@mail:~# stty --all
speed 115200 baud; rows 24; columns 80; line = 0;
intr = ^C; quit = ^; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon ixoff
-iuclc -ixany imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke -flusho -extproc

the output of stty --all in the shell of the hosting system is

speed 38400 baud; rows 39; columns 147; line = 0;
intr = ^C; quit = ^; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -ixon -ixoff -iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc


Get this bounty!!!

#StackBounty: #graphics #virtualization #kvm #display-rotation #spice How to emulate a vertical screen in Xubuntu guest?

Bounty: 50

I am using an Xubuntu guest virtual machine with Virt-Manager, Spice, and QXL. I want to rotate the virtual display to be vertical so as to fit my monitor.

Stuff I tried:

  • Settings > Display in Xubuntu guest: There is a Rotation popup menu, but the only available option is None.
  • Rotating via xrandr doesnt work:
~$ xrandr -q
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
Virtual-0 connected primary 1024x768+0+0 0mm x 0mm
   1024x768      59.95*+
   1920x1200     59.95  
   1920x1080     60.00  
   1600x1200     59.95  
   1680x1050     60.00  
   1400x1050     60.00  
   1280x1024     59.95  
   1440x900      59.99  
   1280x960      59.99  
   1280x854      59.95  
   1280x800      59.96  
   1280x720      59.97  
   1152x768      59.95  
   800x600       59.96  
   848x480       59.94  
   720x480       59.94  
   640x480       59.94  
Virtual-1 disconnected
Virtual-2 disconnected
Virtual-3 disconnected
~$ xrandr --output Virtual-0 --rotate right
xrandr: output Virtual-0 cannot use rotation "right" reflection "none"
  • echo 3 | sudo tee /sys/class/graphics/fbcon/rotate had no effect and gave no error.
  • As far as I can tell, I have the right drivers installed:
~$ apt list --installed | grep -i spice

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

spice-vdagent/bionic,now 0.17.0-1ubuntu2 amd64 [installed]
~$ apt list --installed | grep -i qxl

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

xserver-xorg-video-qxl/bionic,now 0.1.5-2build1 amd64 [installed]
  • My XML looks OK, right?
    <graphics type='spice' autoport='yes'>
      <listen type='address'/>
      <image compression='off'/>
    </graphics>
    <sound model='ich9'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/>
    </sound>
    <video>
      <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
    </video>

Is there a way to have a virtual vertical monitor with a Xubuntu guest?


Get this bounty!!!

#StackBounty: #networking #kvm #qemu #bridge #libvirt qemu/KVM/libvirt usermode networking: VM as a non-root user, what do I need for u…

Bounty: 50

I have run several VMs in KVM/qemu with libvirt, and somehow most of the time networking works.

Now, networking has stopped working when VMs are run as a non-root user. I have found little helpful information in the libvirt and similar documentation pages – most seem to assume that I wish to run the VM as a system user which is not the case.

So: What exactly are the pre-requisites to run a VM with network (e.g. webbrowsing in guest) as non-root?

I have, in myvm.xml:

 94     <interface type='user'>
 95       <mac address='52:54:00:82:f1:27'/>
 96       <model type='virtio'/>
 97       <link state='up'/>
 98       <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
 99     </interface>

The interface is visible from inside the guest, and enabling DHCP client gives an address 10.0.2.5. The default route is 10.0.2.2 which I can ping from within the network. Anything beyond that fails.

My host does not have a network bridge (or any device for/by libvirtd) but I shouldn’t need that for usermode NAT within user-libvirtd, right? Technically the network access comes from user-libvirtd?

The user running libvirtd is in groups kvm and libvirt. Which one do I need for what? The latter is not necessary for running the VM and makes no difference for my problem.

I have enabled and started libvirtd as root on the host but this makes no difference whatsoever. Do I need it at all?

Please note that this VM may not run as root so that would not be a solution for me. The user may not have elevated rights or access to other people’s VMs on the same host.


Get this bounty!!!