11:19 a.m.
On Wed, Sep 07, 2022 at 10:28:17AM -0500, Carlos Bilbao wrote:
On 9/6/22 12:50, Carlos Bilbao wrote:
> So, what I did this time was:
>
> $ ninja -C build clean
I would recommend nuking the build/ directory completely if you're
going to reconfigure, just to be on the safe side.
> $ meson build --reconfigure --prefix=$HOME/usr -Dsystem=true
Passing --prefix along with -Dsystem=true doesn't really make sense.
-Dsystem=true tells the build system to set various paths to sane
defaults for a system-wide installation, and the value passed to
--prefix is used to construct some of those paths. So don't use both
at the same time - stick to -Dsystem=true only.
As an aside, setting --prefix to a directory under $HOME is unlikely
to result in a working configuration anyway.
> $ ninja -C build
> $ sudo ninja -C build install
> $ systemctl stop libvirtd
> $ systemctl start libvirtd
Before restarting libvirtd, since you've just installed new unit
files as part of the steps above, you should run
$ sudo systemctl daemon-reload
> $ systemctl status libvirtd
> ○ libvirtd.service - Virtualization daemon
> Loaded: loaded (/usr/local/lib/systemd/system/libvirtd.service;
> enabled; vendor preset: enabled)
Note how the unit file...
> Active: inactive (dead) since Tue 2022-09-06 17:43:53 UTC;
1min 57s
> ago
> TriggeredBy: ● libvirtd-admin.socket
> ● libvirtd-ro.socket
> ● libvirtd.socket
> Docs: man:libvirtd(8)
> https://libvirt.org
> Process: 2272757 ExecStart=/usr/local/sbin/libvirtd $LIBVIRTD_ARGS
... the libvirtd binary...
> (code=exited, status=0/SUCCESS)
> Main PID: 2272757 (code=exited, status=0/SUCCESS)
> Tasks: 2 (limit: 32768)
> Memory: 60.5M
> CPU: 49ms
> CGroup: /system.slice/libvirtd.service
> ├─2760 /usr/sbin/dnsmasq
> --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro
> --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
> └─2761 /usr/sbin/dnsmasq
> --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro
> --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
>
> Sep 06 17:41:04 host systemd[1]: Starting Virtualization daemon...
> Sep 06 17:41:04 host systemd[1]: Started Virtualization daemon.
> Sep 06 17:41:53 host libvirtd[2272757]: libvirt version: 8.7.0
> Sep 06 17:41:53 host libvirtd[2272757]: hostname: host
> Sep 06 17:41:53 host libvirtd[2272757]: Failed to connect socket to
> '/var/local/run/libvirt/virtqemud-sock': No such file or directory
... and the socket are all under /{usr,var}/local. This is not what
you want, and using -Dsystem=true should have not resulted in such a
setup.
Make sure you run 'systemd daemon-reload' after installing unit
files, as I've mentioned above, and also look around for leftovers
from a previous installation of libvirt that might be interfering
with the current one.
Regardless of all that, the client is trying to connect to virtqemud
but you seem to have the monolithic libvirtd daemon running. I can't
remember whether that's expected, but it's looks like a red flag to
me. I think the client might have gotten confused about whether split
daemons are in use.
Please check out https://libvirt.org/daemons.html and ensure you're
in one of the two supported deployment scenarios and not a weird mix
of the two.
> > Generally the most straightforward way is to build
distribution packages
> > from the tree and install them directly in your system because then you
> > avoid issues such as possibly having two libvirtd instances running and
> > such.
>
> Does libvirt have any script or tool to ease such process?
Answering to myself here, because I have made some progress but still have
to fix some blockings. Decided to use debhelper to build Debian packages
and test libvirt. Did:
$ sudo apt-get install debhelper dh-make
$ sudo dh_make --createorig -p libvirt-snp_1
$ dh_auto_configure --buildsystem=meson
$ dpkg-buildpackage -rfakeroot -us -uc -b
Notice that the option -b for dpkg-buildpackage is to avoid the Debian
package bureaucracy. But still, some checks fail for the package (see below
). I don't think this errors have anything to do with the code I modified,
but I will be happy to share a patch for reproduction.
If you want to build a Debian package, I recommend using the one
that's already in the archive as a starting point instead of using
dh_make to create one from scratch. It's currently a couple of
versions behind upstream, but should be pretty solid otherwise.
dh_make is intended to create a very basic skeleton for a package,
and you're expected to make significant changes to the files it
produces before being able to build a working package.
--
Andrea Bolognani / Red Hat / Virtualization