I'm trying to boot a QEMU VM from a vhost-user-blk-pci device, which appears to be generally possible (https://github.com/spdk/spdk/issues/1728) . In my case, vhost gets the image via SPDK's NVMe-oF driver. However, QEMU does not find a bootable device. What I am doing: 1. Start vhost bin/vhost -S /var/tmp -s 1024 -m 0x3 -A 0000:82:00.1 2. Connect to NVMe-oF server and create blk controller ./rpc.py bdev_nvme_attach_controller -t tcp -a 10.0.0.4 -s 4420 -f ipv4 -n nqn.2024-10.placeholder:bd --name placeholder ./rpc.py vhost_create_blk_controller --cpumask 0x1 vhost.0 placeholdern1 3. Attempt to launch QEMU with blk controller as boot device (does not find anything bootable) taskset -c 2,3 qemu-system-x86_64 \ -enable-kvm \ -m 1G \ -smp 8 \ -nographic \ -object memory-backend-file,id=mem0,size=1G,mem-path=/dev/hugepages,share=on \ -numa node,memdev=mem0 \ -chardev socket,id=spdk_vhost_blk0,path=/var/tmp/vhost.0,reconnect=1 \ -device vhost-user-blk-pci,chardev=spdk_vhost_blk0,bootindex=1,num-queues=2 Things I've checked: * I can mount an NMVe-oF disk to the VM just fine using the same sequence of commands (giving QEMU an additional bootable drive) (just booting from it won't work) * the image on the NVMe-oF server boots just fine if I provide it locally (via the host-kernel NVMe-oF driver that I can't use in production) and declare it in the QEMU options as a drive * QEMU does not appear to have an NVMe-oF driver itself that I could use instead (it does have an NVMe driver) QEMU version 7.2.15 (Debian 1:7.2+dfsg-7+deb12u12) SPDK version SPDK v25.01-pre git sha1 8d960f1d8

this is my first time i'm asking a question so if i can do something better please tell me. I'm not very good in Linux things, so far i could follow along guides and the problems i had where easy fixes with some searching, but now i'm stuck. I have a small homeserver running Debian Buster. On there i run several VM's with libvirt/qemu. My problem is with a nextcloud instance: Yesterday i had a power loss on the system. After rebooting everything was normal so far. Then i wanted to start my VM's and all of them started fine but one. There i get the following error:

sudo virsh start mydomain 
error: Failed to start domain mydomain 
error: internal error: process exited while connecting to monitor: 
qemu-system-x86_64: -realtime mlock=off: warning: '-realtime mlock=...' is deprecated, please use '-overcommit mem-lock=...' instead 
2022-10-01T13:31:17.160445Z qemu-system-x86_64: -drive file=/path/to/mydomain.snapshot1.snapshot2,format=qcow2,if=none,id=drive-virtio-disk0: 
Could not open backing file: Could not open '/path/to/mydomain.snapshot1': Permission denied

I created external snapshot following this guide https://fabianlee.org/2021/01/10/kvm-creating-and-reverting-libvirt-external-snapshots/ And i first thought something was broken with the vm so i tried to revert to an older snapshot (i have one only hours before the powerloss) According to the guide i used these steps to revert:

# edit hda path back to original qcow2 disk
virt-xml $thedomain --edit target=$targetdisk --disk path=$backingfile --update

# validate that we are now pointing back at original qcow2 disk
virsh domblklist $thedomain

# delete snapshot metadata
virsh snapshot-delete --metadata $thedomain $snapshotname

# delete snapshot qcow2 file
sudo rm $pooldir/$thedomain.$snapshotname

# start guest domain
virsh start $thedomain

But after that i still get the same errors just pointing to the snapshot file. Also when i tried to start the VM, the owner and the group of the snapshot file changed from "libvirt-qemu" to "root". I tried to search for the Problem but couldn't find a lot. The closest i found was https://unix.stackexchange.com/questions/435837/how-to-configure-apparmor-so-that-kvm-can-start-guest-that-has-a-backing-file-ch So it might have to do something with apparmor. But i'm confused what changed over the powerloss. But anyway i tried the suggentions in those posts without an effect. But it is also possible that something changed through an update and only came to effect after the reboot. So far the server ran quite well and wasn't shutdown very often. Sorry for the long text. Thanks in advance for any help

I've just configured the passthrough on my ubuntu / I9 9900k / nvidia geforce RTX 2080 ti machine. Now I'm converting the VMware virtual machine VMDK files (created from the conversion of a physical installation of Windows 10) into one big qcow2 file with the following command : mario@ziomario-Z390-AORUS-PRO:/media/ziomario/DATI/DiscoC/DESKTOP-N9UN2H3# qemu-img convert -f vmdk DESKTOP-N9UN2H3*.vmdk -O qcow2 /media/ziomario/WIN/DiscoC/DESKTOP-N9UN2H3/QCOW2/DESKTOP-N9UN2H3.qcow2 The physical installation of Windows 10 has a size of 300 GB. The VMDK files produced by the conversion did with vCenter Converter have a size of 558 GB. I don't know what could be the final size of the converted qcow2 file. What I know is that I tried to save it in a disk of 1 TB and it became full. I would like to know if there is a way to convert more than one VMDK file into a qcow2 or img file (these are the formats accepted by qemu/kvm virt-manager) that will have almost the same size of the original ones. thanks.

i have a headless box running bbqlinux that i'm trying to use as an android-studio development box. when i go to launch an .avd in the emulator, i receive this error: Cannot launch AVD in emulator Output: emulator: ERROR: x86 emulation currently requires hardware acceleration! Please ensure KVM is properly installed and usable. CPU acceleration status: This user doesn't have permissions to use KVM (/dev/kvm). this was freaking me out and i spent a good amount of time trying to sure that everything was enabled, installed correctly, permissions set, etc... then: i plugged a screen in and logged directly into the box and bam! it works fine. so my problem is maybe the vncserver? i'm using tigervnc that i set up according to this page: https://wiki.archlinux.org/index.php/Vncserver just in case it helps, my xstartup file is unset SESSION_MANAGER unset DBUS_SESSION_BUS_ADDRESS [ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources vncconfig -iconic & startxfce4 & other than that, i've not changed the default environment hardly at all except to add lighttable, ssh, & vnc. so my question is really - should i not be doing it this way? is there a better workflow or vnc server program for what i'm trying to do? - is there a command switch or option that i missed that maybe enables the hardware acceleration over vnc? thanks!

I'm running **Proxmox VE 8.4.1**, and I’m experiencing a strange behavior with a **Debian 12 (Bookworm)** VM: the qemu-guest-agent is clearly active and responding, but when I try to shut down the VM via qm shutdown , it never completes. The VM remains stuck in the state:

running (shutdown)

Also, the qm agent ping command returns **no output at all**. --- ### ✅ Working behavior: - Guest has qemu-guest-agent installed and running - Device /dev/virtio-ports/org.qemu.guest_agent.0 exists inside the VM - Agent is enabled via agent: 1 in qm config - Commands like the following return valid JSON:

qm guest cmd  get-osinfo  
qm guest cmd  get-time  
qm guest cmd  get-users  
qm guest cmd  network-get-interfaces

--- ### ❌ Failing behavior: - qm agent ping → **no output, no error** Example:

root@host:~# qm agent 100 ping
root@host:~#

- qm shutdown → executes, but VM remains stuck in "running (shutdown)" state - Restarted host and guest multiple times, same result --- ### 🔧 Setup: **Guest VM (Debian 12):**

# cat /etc/os-release
Debian GNU/Linux 12 (bookworm)

# qemu-ga --version
QEMU Guest Agent 7.2.17 (but tried also with 10.0.0+ds-2~bpo12+2 installed via bookworm-backports and nothing changes)

# ls -l /dev/virtio-ports/
crw------- 1 root root ... org.qemu.guest_agent.0

**Host (Proxmox):**

# pveversion
pve-manager/8.4.1/2a5fa54a8503f96d (running kernel: 6.8.12-11-pve)

# apt show pve-qemu-kvm
Version: 9.2.0-6

--- ### 📜 Logs (from journalctl -xe on the host):

Jul 14 16:20:42 hostname pvedaemon: start VM 100: UPID:hostname:00000000:00000000:00000000:qmstart:100:root@pam:
Jul 14 16:20:42 hostname pvedaemon:  starting task UPID:hostname:00000000:00000000:00000000:qmstart:100:root@pam:
Jul 14 16:20:43 hostname pvedaemon: VM 100 started with PID 516522.
Jul 14 16:20:43 hostname pvedaemon:  end task UPID:hostname:00000000:00000000:00000000:qmstart:100:root@pam: OK
Jul 14 16:20:44 hostname pvedaemon:  starting task UPID:hostname:00000000:00000000:00000000:vncproxy:100:root@pam:
Jul 14 16:20:44 hostname pvedaemon: starting vnc proxy UPID:hostname:00000000:00000000:00000000:vncproxy:100:root@pam:
Jul 14 16:21:08 hostname pvedaemon:  starting task UPID:hostname:00000000:00000000:00000000:qmshutdown:100:root@pam:
Jul 14 16:21:08 hostname pvedaemon: shutdown VM 100: UPID:hostname:00000000:00000000:00000000:qmshutdown:100:root@pam:
Jul 14 16:21:32 hostname pvedaemon:  end task UPID:hostname:00000000:00000000:00000000:vncproxy:100:root@pam: OK
Jul 14 16:21:36 hostname pvedaemon: VM 100 qmp command failed - VM 100 qmp command 'guest-ping' failed - got timeout
Jul 14 16:21:55 hostname pvedaemon: VM 100 qmp command failed - VM 100 qmp command 'guest-ping' failed - got timeout
Jul 14 16:22:14 hostname pvedaemon: VM 100 qmp command failed - VM 100 qmp command 'guest-ping' failed - unable to connect to VM 100 qga socket - timeout after 31 retries

--- ### 🤔 My theory: Since all other guest cmd commands work fine, it seems that **Proxmox is expecting a response from guest-ping**, and when it doesn’t receive it (or receives an empty response), it **fails to confirm the VM shut down properly** — which leads to the stuck "running (shutdown)" state. --- ## ❓ Question: What could be causing guest-ping (used internally by qm agent ping and qm shutdown) to fail or timeout, even when other guest cmd commands succeed? - Is there something about how qemu-ga communicates that might explain why guest-ping isn't acknowledged? - Could this be a bug or mismatch between Proxmox 8.4 and the QEMU Guest Agent in debian, tried bot native 7.2.17 and backports v10? - Is there a proper workaround to allow clean qm shutdown detection without guest-ping? Any insights from people using similar versions (QEMU 9+, guest-agent 10+, Proxmox 8) would be very appreciated. Thanks! --- Some images: Dump of serial after adding the serial port to the vm before the shutdown and after pressing the shutdown button in GUI interface. root@proxmox:~# qm terminal 100 starting serial terminal on interface serial0 (press Ctrl+O to exit) [ 26.693132] reboot: Power down nothing happens on serial after this

I'm making my first steps in FreeBSD, so please excuse any possible "linuxism". My goal is to run FreeBSD 10.2 inside virtual machine with QEMU/KVM and allow USB3 network card passthrough from the host to make it the only available WAN interface. To start QEMU/KVM I run the following: kvm -m 4096 \ -snapshot \ -hda /path/to/the/image \ -device nec-usb-xhci,id=xhci,addr=0x5 \ -device usb-host,bus=xhci.0,vendorid=0x0b95,productid=0x1790 \ -net none This is running fine, if I'm trying to start Ubuntu 16.04. The interface is up, shows up in lsusb and the address is assigned by DHCP. I'm also able to run the very same FreeBSD image with VirtualBox: the card is recognised (as it's supported by FreeBSD) and I see: pciconf -lv #skipped xhci0@pci0:0:12:0: class=0x0c0330 card=0x00000000 chip=0x1e318086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '7 Series/C210 Series Chipset Family USB xHCI Host Controller' class = serial bus subclass = USB When running QEMU monitor, info usb returns (no surprise) the same entry for the network card, both for Ubuntu and FreeBSD. The only way of adding XHCI controller in QEMU I found is to specify nec-usb-xhci, so far this is the only difference between VirtualBox and QEMU I see. Is there a way to make this USB3 passthrough to FreeBSD possible with QEMU?

I didn't create this user - I think it was added by installing the "Virtual Machine manager" (virt-manager) on Debian10/KDE. grep -E 'libvirt|qemu' /etc/passwd returns libvirt-qemu:x:6xxxx:1xx:Libvirt Qemu,,,:/var/lib/libvirt:/usr/sbin/nologin KDE's User Manager doesn't show the account but it's displayed on the login screen on the left of the actual user account. I don't have a file /var/lib/AccountsService/users/libvirt-qemu like described in a solution to the 2017 question here and could not find a bug report if it's due to a bug in accountsservice (why does the bug occur / why hasn't it been fixed since?). **Why is this user created and how to remove it but still be able to use virt-manager?** If the solution is to not remove the user but to hide it by creating the /users/libvirt-qemu file why isn't that done when the user is set up already? If the user is necessary I'd find it strange that iirc it was only added after installing virt-manager but not after installing and using aqemu.

I'm working on an networking lab tool leveraging QEMU-based VM virtualization and docker technology to run VMs and containers respectively on a Linux host. The underlying lab connectivity is implemented by using linux bridges. I have a linux Ubuntu guest running inside a QEMU VM that features a virtio-net paravirualized interface with TAP backend. Such TAP interface is connected to a linux bridge's port on the host. root@eve-ng62-28:~# brctl show vnet0_3 bridge name bridge id STP enabled interfaces vnet0_3 8000.d63b1f37e4ba no vnet0_9_2 vunl0_3_3 vunl0_7_0 vunl0_9_2 root@eve-ng62-28:~# root@eve-ng62-28:~# ethtool -i vunl0_7_0 driver: tun version: 1.6 firmware-version: expansion-rom-version: bus-info: tap supports-statistics: no supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no root@eve-ng62-28:~# I'm using Linux ftrace via trace-cmd frontend to dig into some details, see also https://unix.stackexchange.com/questions/797717/tcp-checksum-offloading-on-virtio-net-paravirtualized-interfaces root@eve-ng62-28:~# trace-cmd start -e net:netif_receive_skb_entry -f "name == 'vunl0_7_0'" root@eve-ng62-28:~# root@eve-ng62-28:~# trace-cmd show # tracer: nop # # entries-in-buffer/entries-written: 1/1 #P:48 # # _-----=> irqs-off/BH-disabled # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / _-=> migrate-disable # |||| / delay # TASK-PID CPU# ||||| TIMESTAMP FUNCTION # | | | ||||| | | qemu-system-x86-600348 b.... 66505.777999: netif_receive_skb_entry: dev=vunl0_7_0 napi_id=0x0 queue_mapping=1 skbaddr=0000000006a1cc35 vlan_tagged=0 vlan_proto=0x0000 vlan_tci=0x0000 protocol=0x0800 ip_summed=3 hash=0x00000000 l4_hash=0 len=60 data_len=0 truesize=768 mac_header_valid=1 mac_header=-14 nr_frags=0 gso_size=0 gso_type=0x0 As you can see, linux guest sends outgoing TCP packets to the virtio-net network interface setting CHECKSUM_PARTIAL(3) tag in the ip_summed field within sk_buff struct. My question is related to the TASK-PID field shown by trace-cmd show. 600348 is the PID of the qemu-system-x86_64 process's instance associated to the VM. As required I edit this to provide the question: is the TASK-PID shown the PID or TID of the process/thread that is the context the TAP driver runs into ?

As explained here in my own Q&A, reconsider the following scenario. A Linux host with a two port Linux bridge and two Linux guest VMs connected to it: the first bridge's port is connected to TAP interface tap0 while the second to tap1. tap0 and tap1 are backend TAP interfaces associated to virtio-net (frontend) interfaces each exposed to a QEMU based VM (lets say VM0 and VM1). As far as I can tell, when VM0 sends a frame/packet targeted to VM1, VM0 QEMU process's userland code calls write() syscall on the fd virtio-net interface is associated to. From tap0 driver-code viewpoint, the RX path is involved (basically tap0 is receiving a packet/frame from its "logical wires"), hence for instance the kernel netif_receive_skb() function is executed in the context of VM0 QEMU's process. Furthermore the packet/frame is forwarded from the Linux bridge to the tap1 interface hence, from tap1 driver-code viewpoint, the TX path is involved (basically tap1 is transmitting a packet/frame on its "logical wires"), hence for instance the kernel net_dev_xmit() function is executed/run in the context of VM0 QEMU's process as well. Does it makes sense ? Thanks.

KVM/QEMU libvirt Network "default" NAT Configuration - Guest can connect to host and the host to guest but the guest cannot connect to Internet(no VPN).

$ sudo virsh net-list --all

  Name      State    Autostart   Persistent
  --------------------------------------------
  default   active   yes         yes

$ sudo virsh net-dumpxml default

default
    f1eff8aa-73e7-4573-8d36-571a85714777
    
      
        
      
    
    
    
    
      
        
      
    
  

$ ip address show dev virbr0

    7: virbr0:  mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:54:00:73:62:06 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
   
$ sudo virsh list

    Id   Name   State
    ----------------------
    3    win7   running

$ sudo virsh dumpxml win7 --xpath //interface
  
     
     
     
     
     
     
   

And the guest ip

>ipconfig

Windows IP Configuration


Ethernet adapter Local Area Connection 2:

   Connection-specific DNS Suffix  . : 
   Link-local IPv6 Address . . . . . : fe80::68b4:6322:b7d9:e1b%13
   IPv4 Address. . . . . . . . . . . : 192.168.122.177
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.122.1

Tunnel adapter isatap.{78EA3F74-7278-48C5-BCA4-1FAC47CD4006}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . : 

$ sudo iptables-save
# Generated by iptables-save v1.8.11 (nf_tables) on Wed Jul  9 22:26:44 2025
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [131442:47715628]
:LIBVIRT_PRT - [0:0]
-A POSTROUTING -j LIBVIRT_PRT
-A LIBVIRT_PRT -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
COMMIT
# Completed on Wed Jul  9 22:26:44 2025
# Generated by iptables-save v1.8.11 (nf_tables) on Wed Jul  9 22:26:44 2025
*filter
:INPUT ACCEPT [21995:13427635]
:FORWARD ACCEPT [2:120]
:OUTPUT ACCEPT [20003:5430042]
:LIBVIRT_FWI - [0:0]
:LIBVIRT_FWO - [0:0]
:LIBVIRT_FWX - [0:0]
:LIBVIRT_INP - [0:0]
:LIBVIRT_OUT - [0:0]
-A INPUT -j LIBVIRT_INP
-A FORWARD -j LIBVIRT_FWX
-A FORWARD -j LIBVIRT_FWI
-A FORWARD -j LIBVIRT_FWO
-A OUTPUT -j LIBVIRT_OUT
-A LIBVIRT_FWI -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A LIBVIRT_FWI -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A LIBVIRT_FWO -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A LIBVIRT_FWO -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A LIBVIRT_FWX -i virbr0 -o virbr0 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A LIBVIRT_OUT -o virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A LIBVIRT_OUT -o virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A LIBVIRT_OUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT
-A LIBVIRT_OUT -o virbr0 -p tcp -m tcp --dport 68 -j ACCEPT
COMMIT
# Completed on Wed Jul  9 22:26:44 2025
# Generated by iptables-save v1.8.11 (nf_tables) on Wed Jul  9 22:26:44 2025
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [3497:641808]
:LIBVIRT_PRT - [0:0]
-A POSTROUTING -j LIBVIRT_PRT
-A POSTROUTING -o enp3s0 -j MASQUERADE
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE
-A LIBVIRT_PRT -s 192.168.122.0/24 -d 224.0.0.0/24 -j RETURN
-A LIBVIRT_PRT -s 192.168.122.0/24 -d 255.255.255.255/32 -j RETURN
-A LIBVIRT_PRT -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A LIBVIRT_PRT -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A LIBVIRT_PRT -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE
COMMIT
# Completed on Wed Jul  9 22:26:44 2025

$ sudo cat /etc/sysctl.conf
vm.swappiness=10
net.ipv4.ip_forward=1

#The host routes
$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 enp3s0
0.0.0.0         192.168.0.1     0.0.0.0         UG    100    0        0 enp3s0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 enp3s0
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 enp3s0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

The guest VM can ping the gateway 192.168.0.1 which is the router's ip and gateway to internet but the VM can not ping the internet such as 8.8.8.8 and for every other VM like GNU/Linux or other, no internet.

I want to test and debug linux kernel internals within the bluetooth stack, i.e. /net/bluetooth. I have a (rather minimal) kernel, manually built, with debug symbols, and a busybox at the moment, running in qemu. Now I want to investigate specific bluetooth functions from the kernel. I thought, a virtual device would be easiest but it seems harder than expected. I found there is btvirt from bluez for dealing with virtual bluetooth devices. I have tried manually building bluez statically. Doesn't work, btvirt is still (at least partly) dynamically linked (and hence doesn't work in my vm):

# in bluez repo
autoreconf -vfi
./configure --enable-static --enable-debug --enable-test --enable-testing --enable-deprecated --enable-experimental --enable-logger CFLAGS=-static LDFLAGS=-static
make
ldd emulator/btvirt  # output below
	linux-vdso.so.1 (0x00007f7225f23000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7225cf5000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f7225f25000)

Also, I tried clang instead of gcc, without success. musl-gcc yielded some error about readline when trying to ./configure I have not followed further yet. What options do I have/which route would be the easiest? 1. Should I abandon my minimal kernel and use a full debian/ubuntu instead? I need debugging symbols and might want to pin to specific versions, so I guess, I would have to manually build the debian/ubuntu kernel (i.e. in accordance with some minimum build flags these distros need/expect), right? 2. How much work is it/should I try to expand my custom small setup with libc, linker etc? 3. Am I on the right track at all? I assume(d) that kernel bluetooth developers might use virtual devices. (Am I correct on that one? If people have experience here, I'd be curious.) Or is this rather hopeless and should I try to pass-through a USB bluetooth device instead? Thanks in advance, I'll be happy to provide further info if needed.

Does anyone know how to get full screen mode working using QEMU on MacOS (Ventura or Monterey)? I tried entering full screen on my 5120 x 2880 resolution display, however Gnome Display Manager doesn't advertise a setting larger then 1620x... I'm wondering if this is something that needs to be set manually in X-Windows.

Problem: I have a new SATA drive I wish to sysprep with a Windows installation. I only have Windows virtualised on my PC. My Solution: Attach (passthrough) the entire drive to the Windows VM and sysprep as normal. This is my VGA/Passthrough script: #!/bin/bash #1st PART configfile=/etc/vfio-pci.cfg vfiobind() { dev="$1" vendor=$(cat /sys/bus/pci/devices/$dev/vendor) device=$(cat /sys/bus/pci/devices/$dev/device) if [ -e /sys/bus/pci/devices/$dev/driver ]; then echo $dev > /sys/bus/pci/devices/$dev/driver/unbind fi echo $vendor $device > /sys/bus/pci/drivers/vfio-pci/new_id } modprobe vfio-pci cat $configfile | while read line;do echo $line | grep ^# >/dev/null 2>&1 && continue vfiobind $line done #2nd PART xrandr --output DVI-D-0 --off /usr/bin/synergys --config /home/%username%/.synergy.conf export QEMU_ALSA_DAC_BUFFER_SIZE=512 QEMU_ALSA_DAC_PERIOD_SIZE=170 QEMU_AUDIO_DRV=alsa sudo qemu-system-x86_64 \ -enable-kvm \ -M q35 \ -m 8192 \ -cpu host,kvm=off,migratable=off,+invtsc,enforce \ -smp 4,sockets=1,cores=4,threads=1 \ -bios /usr/share/seabios/bios.bin -vga none \ -device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \ -device vfio-pci,host=06:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \ -device vfio-pci,host=06:00.1,bus=root.1,addr=00.1 \ -soundhw all \ -drive if=none,file=/media/VM/windows1.img,id=disk,format=raw -device ide-hd,bus=ide.0,drive=disk \ -net tap,vlan=0 \ -boot menu=on sudo killall synergys xrandr --output DVI-D-0 --auto xrandr --output DVI-D-0 --right-of HDMI-0 exit 0 Question 1): I want to make /dev/sdc available to the VM. What -option format will achieve this. (To reiterate the new disk, sdc, has **no** content, partition or formatting at this point.) Question 2): Am I making life stupidly difficult for myself and is there is much simpler solution. Question 3) I do know that this can be achieved by using .xml script that virt-manager uses, but as you see I am not using virt-manager to launch the VM (because of the VGA Pasthrough), would it be possible to convert/import this startup script into the virt-manager .xml format and then add something like: ...to the `` section? Many thanks just for reading to end if you managed it.

Does anyone know the command? I tried the following, however I don't get a login screen, just grub. -nographic. I think the other one which specifies -serial, requires a kernel image provided, which is not what I'm looking for. I think it's about providing grub the correct command line arguments. console=ttyS0

I am running a VM on a Linux host using qemu+kvm and libvirt, the guest system is CentOS 7. I wish to share a folder between the two such that host:/some/dir becomes accessible as guest:/some/other/dir. I wish to minimise effort and cannot re-compile the kernel on either side. I experimented with plan9 but cannot get it to run (the p9 dkms module won't compile on the CentOS 7 guest). There must be a better way? Performance is secondary as it does not work at all right now.

I have a VM running using: qemu-system-x86_64 -m 8192 -smp 3 \ -net user -net nic,model=virtio -boot menu=on \ -drive file=guixsd-usb-install-0.13.0.x86_64-linux \ -drive file=guixsd.img per the [GuixSD VM installation guide](https://www.gnu.org/software/guix/manual/html_node/Installing-GuixSD-in-a-VM.html) (with some slight modifications like the RAM usage, file names and CPU cores allocated). I would like to save the machine state so that I can restore it later (exactly as it was before I saved it, right in the middle of running the guix system init ... command. Sort of the equivalent to the "Save the machine state" option for VirtualBox VMs. I saw this answer https://unix.stackexchange.com/a/361015/27613 but it requires the name of the VM, running virsh list --all doesn't list the name of VMs started via this command. DuckDuckGo searching for answers hasn't revealed anything as most results related to if I had started the VM from virt-manager.

In Virtual Box there is a network type "Internal Network", which is where two or more VMs can communicate with each other only. No network connection to the host or other machines. This is the kind of network I need. Using libvirt I was able to set up an "Isolated Network". According to the libvirt docs "In this mode, guests connected to the virtual switch can communicate with each other, and with the host". This doesn't quite work for me as I need network isolation from the host. Does anyone know how to accomplish this using libvirt? I tried following along with this link and creating a virtual private bridge but couldn't get it to work. https://www.linux-kvm.org/page/Networking

I am trying to get qemu-kvm to boot from my live usb stick. Is this possible?

I'm using QEMU to run debian linux on my windows machine. I setup a filezilla ftp server running on localhost in my windows. I can connect to the ftp server from my windows cmd But i can't connect to ftp server in localhost from my debian linux in qemu I can't connect to localhost, but strangely i can connect to website in internet I don't understand, i can connect to internet but i can't connect to localhost? this gave me the impression that QEMU might be blocking localhost connection, but i'm not entirely sure whether this is true nor why. I'm trying to use ftp to transfer file from my windows to my qemu and vice versa (because i tried other method to share file and no success). Does anyone know how to fix this problem ??

How do you share between the two? I have booted my image on my Windows 10 host using this: qemu-system-x86_64 -hda debian.img -m 512 -net user,smb=C:\users\jason\Desktop\sharing\ -net nic,model=virtio In the guest I tried to connect to Samba through this: smbclient //10.0.2.4/qemu This returns Connection to 10.0.2.4 failed (Error NT_STATUS_HOST_UNREACHABLE) I also tried smbclient //10.0.2.15/qemu which returned DOMAIN=[WORKGROUP] OS=[Windows 6.1] Server=[Samba 4.5.16-Debian] tree connect failed: NT_STATUS_BAD_NETWORK_NAME The /tmp and /mnt directories remain empty.