- Users - libvirt List Archives

machinectl does not show libvirtd vms
by Ismael Bouya 28 Jul '20

28 Jul '20

(this is a follow-up of a discussion on IRC with mprivozn) Hello, I’m facing an issue where systemd-machined is not aware of new VMs happening in libvirt (with QEMU). I attached debug logs for a VM starting. To repeat the discussion that happened on IRC: - libvirt config does not specify anything related to cgroup_controllers - cgroups are mounted (mount | grep cgroup is not empty) - in libvirtd.service I see no mention of cgroups (apart from comments related to TasksMax and LimitMEMLOCK) I’m suspecting a packaging issue in my distribution (NixOS) but I’m not really sure where I should look at to solve it. NB: the reason I wanted machinectl was to make use of nsswitch mymachines facilities, which I learnt wouldn’t work anyway. So I’m only reporting it in case something needs to be fixed (probably in my distribution packaging). -- Ismael

1 0

Re: Routed network can't reach outside network
by Rui Correia 24 Jul '20

24 Jul '20

Hi Ken, Of course I did it all by hand. :-D No, I didn't. I'm a fraud. I used http://asciiflow.com/ which asks you to register in order to save your drawings in their cloud. If you don't register, you can still draw and export your drawings, but you can't save them for reusing those later. I see I've missed a couple of posts in this small thread. I was under the impression that I had subscribed to the list but apparently I'm only receiving the messages directly addressed to me. Hence why I took so much time to reply. I'll try to subscribe again. Thank you all in advance. Cheers, Rui Correia On Thu, Jul 23, 2020 at 3:31 PM Marc Roos <M.Roos(a)f1-outsourcing.eu> wrote: > > > > > you must be an ASCII charting demigod. Did you use software to make > those, or do > > them yourselves? Either way, I'm impressed... > > Search for AsciiArtStudio.exe > > > > >

1 0

virt-install missing parameters
by David 23 Jul '20

23 Jul '20

Hello, Hopefully this is the right place to send a question like this... I'm attempting to automate creation of VMs using virt-install and a cloud-init disk image. To get this to work, I need to specify the location of the cloud-init configs by passing smbios key/value pairs. Normally, -smbios is provided to qemu to do this. With virt-install, the Internet says I should use --sysinfo. However, --sysinfo (as well as --qemu-comandline) is reported as an invalid command flag, and it is not present when I look at man virt-install and virt-install --help. I am hoping someone on the list knows why this isn't working or can explain how I might provide the arguments to qemu. The host is Debian 9. It is up-to-date as far as package versions are concerned, as much as Debian 9 can be. I can't find any indication about why the arguments would have been taken away. Thanks!

1 0

host and vm on isolated network, there is ip (via dhcp) but not ping
by daggs 22 Jul '20

22 Jul '20

Greetings, I've setup an vm with openwrt in it, defined a isolated lan between the vm and the host and booted the vm up. I see the vm is up, made sure the vnic is visible in both the host and guest and added it to the br in the guest. I've issued an dhcpd call on the vnic (labeled vnic0) in the host and got an ip, see: dagg@NCC-5001D ~ $ dhcpcd vnet0 DUID 00:01:00:01:23:dd:d8:5b:e0:d5:5e:d9:f2:e2 vnet0: IAID 00:10:20:bf vnet0: rebinding lease of 192.168.1.130 vnet0: probing address 192.168.1.130/24 vnet0: soliciting an IPv6 router vnet0: leased 192.168.1.130 for 43200 seconds vnet0: adding route to 192.168.1.0/24 vnet0: adding default route via 192.168.1.1 forked to background, child pid 26279 dagg@NCC-5001D ~ $ ifconfig virtsw0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 ether 52:54:00:3e:3f:88 txqueuelen 1000 (Ethernet) RX packets 123098 bytes 16327962 (15.5 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 6 bytes 252 (252.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 vnet0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.130 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::fc54:ff:fe10:20bf prefixlen 64 scopeid 0x20<link> ether fe:54:00:10:20:bf txqueuelen 1000 (Ethernet) RX packets 45 bytes 8002 (7.8 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 39 bytes 2676 (2.6 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 dagg@NCC-5001D ~ $ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. ^C --- 192.168.1.1 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1018ms the vm's xml can be found at https://pastebin.com/1gXBGcPb virtsw0 is defined as follows: <network connections='1'> <name>virtsw0</name> <uuid>c8eb15a3-cc5c-4bd6-8f3b-5790792ddccc</uuid> <bridge name='virtsw0' stp='on' delay='0'/> <mac address='52:54:00:3e:3f:88'/> </network> the os is gentoo, the versions are libvirt-6.2.0 qemu-5.0.0. I have another server running debian 10 with the same virtsw0 definition, there the connection is working. /var/lib/libvirt/dnsmasq/virtsw0.macs has only [] in it, can that be the issue? Thanks, Dagg.

2 2

dns test 2
by NO SPAM 22 Jul '20

22 Jul '20

please ignore

1 0

incomplete features for external snapshot
by Henry lol 21 Jul '20

21 Jul '20

as far as I know, deleting/reverting features for external snapshot are not being supported for long time. I'm wondering why it takes so long time and what is the main problem even though those tasks can be done manually. thanks.

1 0

dns test
by NO SPAM 21 Jul '20

21 Jul '20

please ignore

1 0

9p file sharing issue
by Johan 20 Jul '20

20 Jul '20

I've run into an issue with 9p file sharing that I suspect is a bug. I'm running some Debian ARM VMs (armhf Ubuntu guests on an aarch64 Debian stretch host in case that matters). I'm using direct kernel boot, so I'm also using 9p host file sharing so that kernel updates from within the guest would work. However, I've noticed that dpkg (the Debian/Ubuntu package manager) fails when writing into a /boot directory that's shared from the host via 9p. Some investigation reveals that this is because dpkg does an openat() call of the type openat(AT_FDCWD, "/boot/vmlinuz-4.15.0-111-generic-lpae.dpkg-new", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 000); and that it's the 0 permissions mode (last parameter) that causes the call to fail with a "Permission denied" error. A simple test program that does the above openat() call but with another mode (say, 600) works just fine. Some further data: * QEMU runs as the unprivileged user libvirt-qemu (Debian default) * QEMU is version 2.8, libvirt version 3.0.0 * XML snippet for 9p setup: <filesystem type='mount' accessmode='squash'> <source dir='/host/path/boot-test9p'/> <target dir='boot_mount'/> <alias name='fs0'/> <address type='pci' domain='0x0000' bus='0x03' slot='0x01' function='0x0'/> </filesystem> * The 9p filesystem is mounted by this line in /etc/fstab on the guest: boot_mount /boot 9p rw,dirsync,_netdev,relatime,trans=virtio,version=9p2000.L 0 0 The essential problem seems to be that opening a file with a mode of 0 is not compatible with the "squash" 9p access mode. Is this expected? Thank you, Johan

1 0

Unable to decode message length
by Valentin David 16 Jul '20

16 Jul '20

Hello all, I have been trying to get libvirtd to work but when I connect to it with virsh, I get "error : virNetMessageDecodeLength:131 : Unable to decode message length" This happens with libvirt 6.1.0, libtirpc 1.2.6, rpcsvc-proto 1.4.1. I have tried with other versions, but I still get the same error. If anybody has any tip on what to try next, that would be helpful. Thank you in advance. Here is the debug log of libvirtd when I try to connect with virsh: 2020-07-14 16:29:58.220+0000: 5352: info : virEventGLibHandleDispatch:116 : EVENT_GLIB_DISPATCH_HANDLE: watch=2 events=1 cb=0x7f7b55b86c50 opaque=0x556fbcf8b8a0 2020-07-14 16:29:58.220+0000: 5352: info : virObjectNew:250 : OBJECT_NEW: obj=0x556fbcf8d770 classname=virNetSocket 2020-07-14 16:29:58.220+0000: 5352: info : virNetSocketNew:278 : RPC_SOCKET_NEW: sock=0x556fbcf8d770 fd=18 errfd=-1 pid=0 localAddr=127.0.0.1;0, remoteAddr=127.0.0.1;0 2020-07-14 16:29:58.220+0000: 5352: info : virObjectNew:250 : OBJECT_NEW: obj=0x556fbcf8da50 classname=virNetServerClient 2020-07-14 16:29:58.220+0000: 5352: info : virObjectRef:385 : OBJECT_REF: obj=0x556fbcf8d770 2020-07-14 16:29:58.220+0000: 5352: info : virEventGLibTimeoutAdd:341 : EVENT_GLIB_ADD_TIMEOUT: timer=1 interval=-1 cb=0x7f7b55b8d490 opaque=0x556fbcf8da50 ff=(nil) 2020-07-14 16:29:58.220+0000: 5352: info : virNetServerClientNewInternal:421 : RPC_SERVER_CLIENT_NEW: client=0x556fbcf8da50 sock=0x556fbcf8d770 2020-07-14 16:29:58.220+0000: 5352: info : virObjectRef:385 : OBJECT_REF: obj=0x556fbcf8da50 2020-07-14 16:29:58.220+0000: 5352: info : virObjectRef:385 : OBJECT_REF: obj=0x556fbcf8d770 2020-07-14 16:29:58.220+0000: 5352: info : virEventGLibHandleAdd:160 : EVENT_GLIB_ADD_HANDLE: watch=11 fd=18 events=1 cb=0x7f7b55b86c50 opaque=0x556fbcf8d770 ff=0x7f7b55b86c00 2020-07-14 16:29:58.220+0000: 5352: info : virObjectRef:385 : OBJECT_REF: obj=0x556fbcf8da50 2020-07-14 16:29:58.220+0000: 5352: info : virNetServerCheckLimits:280 : Re-enabling services 2020-07-14 16:29:58.220+0000: 5352: info : virEventGLibHandleUpdate:194 : EVENT_GLIB_UPDATE_HANDLE: watch=2 events=1 2020-07-14 16:29:58.220+0000: 5352: info : virObjectNew:250 : OBJECT_NEW: obj=0x556fbcf8e330 classname=virKeepAlive 2020-07-14 16:29:58.220+0000: 5352: info : virKeepAliveNew:208 : RPC_KEEPALIVE_NEW: ka=0x556fbcf8e330 client=0x556fbcf8da50 2020-07-14 16:29:58.220+0000: 5352: info : virObjectRef:385 : OBJECT_REF: obj=0x556fbcf8da50 2020-07-14 16:29:58.220+0000: 5352: info : virObjectUnref:347 : OBJECT_UNREF: obj=0x556fbcf8da50 2020-07-14 16:29:58.220+0000: 5352: info : virObjectUnref:347 : OBJECT_UNREF: obj=0x556fbcf8d770 2020-07-14 16:29:58.220+0000: 5352: info : virEventGLibHandleDispatch:116 : EVENT_GLIB_DISPATCH_HANDLE: watch=11 events=1 cb=0x7f7b55b86c50 opaque=0x556fbcf8d770 2020-07-14 16:29:58.220+0000: 5352: error : virNetMessageDecodeLength:131 : Unable to decode message length 2020-07-14 16:29:58.220+0000: 5352: info : virKeepAliveStop:300 : RPC_KEEPALIVE_STOP: ka=0x556fbcf8e330 client=0x556fbcf8da50 2020-07-14 16:29:58.221+0000: 5352: info : virObjectRef:385 : OBJECT_REF: obj=0x556fbcf8da50 2020-07-14 16:29:58.221+0000: 5352: info : virObjectUnref:347 : OBJECT_UNREF: obj=0x556fbcf8e330 2020-07-14 16:29:58.221+0000: 5352: info : virObjectUnref:349 : OBJECT_DISPOSE: obj=0x556fbcf8e330 2020-07-14 16:29:58.221+0000: 5352: info : virKeepAliveDispose:221 : RPC_KEEPALIVE_DISPOSE: ka=0x556fbcf8e330 2020-07-14 16:29:58.221+0000: 5352: info : virObjectUnref:347 : OBJECT_UNREF: obj=0x556fbcf8da50 2020-07-14 16:29:58.221+0000: 5352: info : virObjectUnref:347 : OBJECT_UNREF: obj=0x556fbcf8da50 2020-07-14 16:29:58.221+0000: 5352: info : virObjectRef:385 : OBJECT_REF: obj=0x556fbcf8da50 2020-07-14 16:29:58.221+0000: 5352: info : virObjectUnref:347 : OBJECT_UNREF: obj=0x556fbcf8da50 2020-07-14 16:29:58.221+0000: 5352: info : virEventGLibHandleRemove:261 : EVENT_GLIB_REMOVE_HANDLE: watch=11 2020-07-14 16:29:58.221+0000: 5352: info : virObjectUnref:347 : OBJECT_UNREF: obj=0x556fbcf8d770 2020-07-14 16:29:58.221+0000: 5352: info : virNetServerCheckLimits:280 : Re-enabling services 2020-07-14 16:29:58.221+0000: 5352: info : virEventGLibHandleUpdate:194 : EVENT_GLIB_UPDATE_HANDLE: watch=2 events=1 2020-07-14 16:29:58.221+0000: 5352: info : virObjectUnref:347 : OBJECT_UNREF: obj=0x556fbcf8da50 2020-07-14 16:29:58.221+0000: 5352: info : virEventGLibHandleRemoveIdle:242 : EVENT_GLIB_REMOVE_HANDLE_IDLE: watch=11 ff=0x7f7b55b86c00 opaque=0x556fbcf8d770 2020-07-14 16:29:58.221+0000: 5352: info : virObjectUnref:347 : OBJECT_UNREF: obj=0x556fbcf8da50 2020-07-14 16:29:58.221+0000: 5352: info : virObjectUnref:349 : OBJECT_DISPOSE: obj=0x556fbcf8da50 2020-07-14 16:29:58.221+0000: 5352: info : virNetServerClientDispose:976 : RPC_SERVER_CLIENT_DISPOSE: client=0x556fbcf8da50 2020-07-14 16:29:58.221+0000: 5352: info : virEventGLibTimeoutRemove:437 : EVENT_GLIB_REMOVE_TIMEOUT: timer=1 2020-07-14 16:29:58.221+0000: 5352: info : virObjectUnref:347 : OBJECT_UNREF: obj=0x556fbcf8d770 2020-07-14 16:29:58.221+0000: 5352: info : virObjectUnref:349 : OBJECT_DISPOSE: obj=0x556fbcf8d770 2020-07-14 16:29:58.221+0000: 5352: info : virNetSocketDispose:1332 : RPC_SOCKET_DISPOSE: sock=0x556fbcf8d770 2020-07-14 16:29:58.221+0000: 5352: info : virEventGLibTimeoutRemoveIdle:417 : EVENT_GLIB_REMOVE_TIMEOUT_IDLE: timer=1 ff=(nil) opaque=0x556fbcf8da50

2 3

SELinux labels change in libvirt
by Ram Lavi 16 Jul '20

16 Jul '20

Hello all, tl;dr, can you point me to the point in the libvirt repo where it's trying to change a tap-device's SELinux label? I am trying to create a tap device with libvirt on a super-privileged container, and then use it on another, unprivileged container with libvirt. User wise, I know I need the super-privileged container to open the tap device with the user of the unprivileged one - that I already did and it's not the issue. But I have a problem when I open the tap device in the non-privileged container: the tap device currently has the spc_t label since the tun_socket inherited the selinux context from the super-privileged container who creates it. then libvirt is trying to change the SELinux labels, and since it's not privileged then it fails. But I didn't find where and how libvirt is trying to change the tap device's label. Can you point me to that specific code on libvirt? Ram Lavi Senior Software Engineer Red Hat Israel <https://www.redhat.com/> Yerushalaim Road 34, Ra'anana ralavi(a)redhat.com IM: ralavi @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com/>

2 5