Questions on device-added and device-removed events
Hi developers, When the guest OS is booting, the event for live attachment could be caught by libvirt, while the event for live detachment could not. Version: libvirt-7.9 qemu-kvm-6.1 Steps: Terminal 1: ➜ ~ virsh event --loop --all Terminal 2: ➜ ~ virsh start avocado-vt-vm1; qemu-img create /tmp/vdb 10M; virsh attach-disk avocado-vt-vm1 /tmp/vdb vdb; virsh detach-disk avocado-vt-vm1 vdb The outputs from terminal 1: event 'agent-lifecycle' for domain 'avocado-vt-vm1': state: 'disconnected' reason: 'domain started' event 'lifecycle' for domain 'avocado-vt-vm1': Resumed Unpaused event 'lifecycle' for domain 'avocado-vt-vm1': Started Booted event 'device-added' for domain 'avocado-vt-vm1': virtio-disk1 event 'agent-lifecycle' for domain 'avocado-vt-vm1': state: 'connected' reason: 'channel event' As you can see, the device live attachment and the device detachment are both executed when the guest OS is booting, but there is only the event 'device-added' is recorded. So my questions are: 1. Is it the expected results for the results above? 2. If so, what is the internal difference between 'device-added' and 'device-removed'? 3. I notice there is the DEVICE_DELETED event in qmp? Any relation between the 'device-removed' of libvirt and the DEVICE_DELETED of qmp?
Re: configure path name of ebtables executable
On 11/17/21 4:52 PM, Michael Ströder wrote: On 11/17/21 20:28, Laine Stump wrote: On 11/17/21 1:39 PM, Michael Ströder wrote: Is it possible to configure the full path name of the ebtables executable used somewhere in libvirt's config? That's done in meson.build when you're building from source. Look for "optional_programs". Noted. Thanks. Background: I'd like to avoid automatic alternatives implementation to mess up libvirt installation. See also: https://bugzilla.opensuse.org/show_bug.cgi?id=1192799 I don't think the problem is what is being suggested in that bug. Yes, it is. The suggestion in that bug is that the problem is because "libvirt need /sbin/ebtables point to ebtables-legacy", which is definitely not the case. libvirt only requires that /sbin/ebtables point to a binary that correctly understands and acts on any valid ebtables command. If the binary pointed to by /sbin/ebtables doesn't do that, then it shouldn't be pointed to by /sbin/ebtables. follow the symlink from /sbin/ebtables to (probably) /etc/alternatives/ebtables > [..] This sounds more like SUSE has some sort of special off-brand alternative that doesn't understand all valid ebtables commands openSUSE Tumbleweed now uses libalternatives for ebtables (see my comment#2) and thus /sbin/ebtables was linked to /usr/bin/alts. Yes, something's broken there and I was looking for a work-around. Anyway, I think you'd be better off fixing the problem at the source rather than trying to make some special local build of libvirt to work around the problem. IMHO a libvirtd.conf option would be great to avoid relying on this alternatives stuff. There are many things within libvirt that we could do ourselves in order to avoid relying on some other package (or add a config knob to point at something different to do the work), but that just makes more code that must be maintained forever. Working around bugs in other packages with package-local fixes and config knobs is a never-ending unwinnable battle once you start, and leads to unnecessarily complicated code and technical debt (I say this from painful experience - although it's a bit of a whatabout-ism, if I had the time (I unfortunately don't :-)) I would tell the story of iptablesAddOutputFixUdpChecksum, just as one example). I think a better road in this case (and most other cases) would be to fix the package that is broken (sounds like libalternatives). If it is breaking libvirt, it's likely breaking other things as well.
Re: configure path name of ebtables executable
On 11/17/21 1:39 PM, Michael Ströder wrote: HI! Is it possible to configure the full path name of the ebtables executable used somewhere in libvirt's config? That's done in meson.build when you're building from source. Look for "optional_programs". Background: I'd like to avoid automatic alternatives implementation to mess up libvirt installation. See also: https://bugzilla.opensuse.org/show_bug.cgi?id=1192799 I don't think the problem is what is being suggested in that bug. Your claim about /etc/alternatives in comment 3 doesn't make any sense - I have ebtables-2.0.11 installed on my Fedora machine, and it is using /etc/alternatives, and I don't get that error message. Try running this command: /sbin/ebtables -t nat -N xyzzy and see if it gives you the same error. If it does, then follow the symlink from /sbin/ebtables to (probably) /etc/alternatives/ebtables and to the final destination from there - you should either end up with /usr/sbin/ebtables-legacy or /usr/sbin/ebtables-nft. If you don't, then your "alternatives" stuff is messed up, and you need to fix that. I just checked the current source code for ebtables and the word "subcommand" doesn't appear anywhere in it. This sounds more like SUSE has some sort of special off-brand alternative that doesn't understand all valid ebtables commands (because the command being complained about in the error message in the bug *is* a valid ebtables commandline); maybe something that put's a shell script wrapper around calling ebtables or something?. If so, you need to switch away from that alternative, or somebody needs to fix the alternative. Anyway, I think you'd be better off fixing the problem at the source rather than trying to make some special local build of libvirt to work around the problem.
