January 2026 - Users - libvirt List Archives

[libvirt-users] bridge / ubuntu / no arp reply
by François Chenais 15 Oct '26

15 Oct '26

Hello I'm trying to setup a bridged guest on an ubuntu 13.10 but it doesn't work. (Everything is ok with NAT) Network sniffing shows that arp replies don't come back to the guest. Test 1 ------ Guest : ping host_bridge_ip (ok) Test 2 ------ Guest: ping other_lan_host (KO) other_lan_host - receives arp who-is request - sends arp reply - arp -a shows the guest macaddr => Guest doesn't receive reply Test 3 ------ other_lan_host ping the Guest (KO) - arp -a shows "incomplete" addr - Guest receives nothing On Host ------- network tcpdump on bridge or vnet interfaces shows request but no reply ... Thanks in advance for help or ideas François

3 4

Writeback vs default cache modes
by João Jandre 04 Mar '26

04 Mar '26

Hi, all I've been reading the QEMU documentation, the Libvirt documentation, as well as doing some testing and code investigation regarding disk cache modes. In the Libvirt documentation, it is stated that the disk driver cache modes accepted are "default", "none", "writethrough", "writeback", "directsync" and "unsafe". Analyzing the code, we can see that this is somewhat reflected on the cache modes that QEMU documents on the -drive option (https://qemu-project.gitlab.io/qemu/system/invocation.html) https://github.com/libvirt/libvirt/blob/04c1f458313e9001f5a804a898408e1f498… However, the default option (when we do not define the "cache" option) is different from other options and does not seem to map to any option on the Qemu side. I see that, from testing and analyzing the code, if the default (not defining the "cache" options) is used, cache.direct and cache.no-flush are not informed; also, the write-cache option is not informed. Just for comparison, here is a disk defined with cache=writeback: XML: |<disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='writeback'/> <source file='/mnt/a66f48f5-13c6-3676-b320-a15d32bbf32f/c0e925a9-6697-4ee9-8abf-d36c7a95cea4' index='2'/> <backingStore type='file' index='3'> <format type='qcow2'/> <source file='/mnt/a66f48f5-13c6-3676-b320-a15d32bbf32f/0db52809-9f33-43ac-8151-5452e9dee330'/> <backingStore/> </backingStore> <target dev='vda' bus='virtio'/> <serial>c0e925a966974ee98abf</serial> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk> | Generated QEMU command: |-blockdev {"driver":"file","filename":"/mnt/a66f48f5-13c6-3676-b320-a15d32bbf32f/c0e925a9-6697-4ee9-8abf-d36c7a95cea4","node-name":"libvirt-2-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":false,"no-flush":false},"driver":"qcow2","file":"libvirt-2-storage","backing":"libvirt-3-format"} -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=libvirt-2-format,id=virtio-disk0,bootindex=2,write-cache=on,serial=c0e925a966974ee98abf | And here is a disk that does not have the cache option: XML: |<disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/mnt/b59eff0f-5b97-37ed-a513-9e1983d1d19b/b430296b-0924-412e-a7b1-ddc3d4c90f83' index='2'/> <backingStore/> <target dev='vdc' bus='virtio'/> <serial>b430296b0924412ea7b1</serial> <alias name='virtio-disk2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </disk> | Generated QEMU command: |blockdev {"driver":"file","filename":"/mnt/b59eff0f-5b97-37ed-a513-9e1983d1d19b/b430296b-0924-412e-a7b1-ddc3d4c90f83","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":null} -device virtio-blk-pci,bus=pci.0,addr=0x8,drive=libvirt-2-format,id=virtio-disk2,serial=b430296b0924412ea7b1 | The QEMU documentation states in the -drive option that the default cache mode is |Writeback| (see https://qemu-project.gitlab.io/qemu/system/invocation.html) so I expected that setting |Writeback| or |Default| as the cache mode on Libvirt would also be the same. I ran some performance tests using both options to try and verify if they were the same, but they are clearly different. For each of the configuration profiles below, I created a VM and ran some fio tests: Combination Disk cache mode Disk Controller IO thread IO policy hds0i default virtio-scsi 0 iouring hds0t default virtio-scsi 0 threads hds1i default virtio-scsi 1 iouring hds1t default virtio-scsi 1 threads hdv0i default virtio 0 iouring hdv0t default virtio 0 threads hdv1i default virtio 1 iouring hdv1t default virtio 1 threads wbs0i writeback virtio-scsi 0 iouring wbs0t writeback virtio-scsi 0 threads wbs1i writeback virtio-scsi 1 iouring wbs1t writeback virtio-scsi 1 threads wbv0i writeback virtio 0 iouring wbv0t writeback virtio 0 threads wbv1i writeback virtio 1 iouring wbv1t writeback virtio 1 threads The fio test results are in a html attached to the email. I would like to understand what the practical difference is between not informing the cache and any other option. I can see that the disk is defined in different way, but just by analyzing the code I was not able to understand what that leads to; also, looking at the performance tests, we clearly see a difference in the results. Would anyone be able to explain what is the expected behavior when the disk is defined in such a way? By the way, I'm using Libvirt 8.0.0 and Qemu 6.2.0. Best regards, João Jandre

3 2

Migration pull vs. push
by johnt＠panix.com 02 Feb '26

02 Feb '26

The migration examples I've found I was able to repeat the steps successfully. They follow the pattern of what I am calling a "push". You are logged into the source hypervisor you want to migrate from and run something like "virsh migrate --live <local VM name> qemu://<Destination Hypervisor>/system" My question is if libvirt support a "pull" migration? Where the user starts on the destination node and "pulls" a VM to itself from the source node. -John

3 2

virt-install - preseed.cfg
by Andrés Miranda 22 Jan '26

22 Jan '26

Hola Comunidad, necesito ayuda. Estoy creando una máquina virtual 100% headless, pero al momento de ejecutar, se detiene y me muestra el instalador en modo texto. Comparto la estructura: cat <<EOF > preseed.cfg # Localización y Teclado d-i debian-installer/locale string es_CO.UTF-8 d-i debian-installer/language string es d-i debian-installer/country string CO d-i localechooser/supported-locales multiselect es_CO.UTF-8 d-i keyboard-configuration/xkb-keymap select latam d-i keyboard-configuration/layoutcode string latam # Configuración de Red (Modo NAT/DHCP) d-i netcfg/choose_interface select auto d-i netcfg/get_hostname string machine d-i netcfg/get_domain string local d-i netcfg/link_wait_timeout string 10 d-i netcfg/dhcp_timeout string 60 # Espejo (Mirror) - Estados Unidos, Sin Proxy d-i mirror/country string manual d-i mirror/http/hostname string deb.debian.org d-i mirror/http/directory string /debian d-i mirror/http/proxy string # Configuración de APT d-i apt-setup/non-free-firmware boolean true d-i apt-setup/contrib boolean true d-i apt-setup/non-free boolean true # Cuentas de Usuario d-i d-i d-i d-i d-i d-i d-i # Zona Horaria - Bogotá, Colombia d-i clock-setup/utc boolean true d-i time/zone string America/Bogota d-i clock-setup/ntp boolean true # Particionado Automático (Todo el disco - Recomendado) d-i partman-auto/disk string /dev/vda d-i partman-auto/method string regular d-i partman-lvm/device_remove_lvm boolean true d-i partman-md/device_remove_md boolean true d-i partman-auto/choose_recipe select atomic d-i partman-partitioning/confirm_write_new_label boolean true d-i partman/choose_partition select finish d-i partman/confirm boolean true d-i partman/confirm_nooverwrite boolean true d-i partman-auto/confirm boolean true d-i partman-auto/confirm_nooverwrite boolean true # Selección de Software (SSH Server + Utilidades estándar) tasksel tasksel/first multiselect standard, ssh-server d-i pkgsel/include string build-essential d-i pkgsel/upgrade select full-upgrade popularity-contest popularity-contest/participate boolean false # Instalación del Cargador de Arranque (GRUB) d-i grub-installer/only_debian boolean true d-i grub-installer/bootdev string /dev/vda # Finalización (Reinicio automático tras terminar) d-i finish-install/reboot_in_progress note EOF sudo virt-install \ --name debian12 \ --vcpus 2 \ --memory 2048 \ --disk size=20,bus=virtio,format=qcow2 \ --os-variant debian12 \ --network network=default,model=virtio \ --graphics none \ --console pty,target_type=serial \ --location https://deb.debian.org/debian/dists/bookworm/main/installer-amd64/ \ --initrd-inject=./preseed.cfg \ --extra-args "auto=true priority=critical preseed/file=/preseed.cfg console=ttyS0,115200n8" \ --check all=off Error: Una vez ejecutado, me muestra el instalador gráfico. Saludos !

3 2

Direct passthrough of /dev/lp0
by billehhg1＠gmail.com 12 Jan '26

12 Jan '26

I want to give multiple domains access to my parallel printer. Can I share hardware parallel port with libvirt?

3 2

Qemu/libvirt with gpu acceleration on c9 ?
by lejeczek 08 Jan '26

08 Jan '26

Hi guys. Do you know if with centos9 it's possible to get graphics/video acceleration - but not as pass-through to host device "directly" ? I'm fiddling with things but without success, with different bits in guest: ... <devices> ... <graphics type='vnc'> <listen type='none'/> <gl enable='yes' rendernode='/dev/dri/by-path/pci-0000:04:00.0-render'/> </graphics> <audio id='1' type='none'/> <video> <model type='virtio' heads='1' primary='yes'>  <acceleration rendernode='/dev/dri/by-path/pci-0000:04:00.0-render'/>  </model>  <driver name='vhostuser'/> <alias name='video0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </video> Comments within XML - basically describe the issue, I hope. Is the issue steaming from Qemu/build - and if yes then, can building Qemu with some flags fix it? - or is this rather hardware side of things most likely the root cause? qemu-kvm-core-10.1.0 + libvirt-libs-11.9.0 many thanks, L.

1 0