Unit libvirtd.service could not be found. on VM

Dana Elfassy delfassy at redhat.com
Wed May 13 10:59:13 UTC 2020


Thanks, Michal,
On my laptop I do have libguestfs and libvirt-daemon-qemu. both
libvirtd.service and libvirtd.socket are running ok on my laptop
I just realized I haven't mentioned - my vms intend to serve as hosts
themselves, and that's why they, too, need to have libvirtd.service running
on them.
up to recently I didn't have such a problem when I installed a vm on my
laptop - libvirtd.service was found on it. I don't know exactly what caused
this to change. Maybe it has something to do with configurations/
permissions of libvirt/ kvm?
Earlier, I'm not sure how, I managed to have libvirtd.service on a vm I
created. it wasn't running, but at least it was there. I'm not sure what I
have changed, but now I'm getting the message that the service could not be
found again
Dana

On Wed, May 13, 2020 at 12:26 PM Michal Privoznik <mprivozn at redhat.com>
wrote:

> On 5/12/20 1:41 PM, Dana Elfassy wrote:
> > if I understand correctly then I shouldn't have installed libvirt-daemon
> > on the guests VMs?
> >
> >
>
> Just a little background to Daniel's response. Libvirt and QEMU treat
> guests as black boxes, to some extent. There are some exceptions to this
> rule, when it comes to para-virtualization (that is when the guest knows
> it is running virtualized and therefore can optimize some things). The
> perfect example is virtio (which are para-virtualized devices like NIC,
> disk, etc.). Depending on the guest the virtio drivers are either
> already installed (majority of Linux distributions including CentOS, if
> not all of them) or they have to be installed separately (Windows is
> typical example).
>
> Then, some tasks can be performed only if there is a small program
> running inside the guest (so called guest agent), which listens for
> incoming commands, executes them and sends the result back to libvirt.
> In CentOS this is qemu-guest-agent RPM. As mentioned, guest agent needs
> a channel to talk to libvirt which can be configured through virsh
> directly [1], or in virt-manager (if not already present, but I guess
> virt-install adds it automatically): Add hardware -> Channel -> Name:
> org.qemu.guest_agent.0 -> Finish.
>
> Some management applications have their own guest agents (e.g.
> libguestfs), but I wouldn't worry about them - the management
> application will configure them automatically; and you are not using
> them anyway.
>
>
> However, on the host the set of packages needed is different (note, you
> don't need any virtio drivers - they are contained in qemu already; nor
> you need the guest agent). libvirt-daemon-driver-qemu is the package
> containing qemu driver for libvirt. However, in order to use other
> features libvirt provides I suggest installing 'libvirt-daemon-kvm'
> which drags in the rest of packages (e.g. storage driver, network
> driver, etc.)
>
> The host is also where you need libvirtd running (systemctl enable
> libvirtd.service  or if you want to use socket activation then:
> systemctl enable libvirtd.socket)
>
> Michal
>
>
> 1: https://wiki.libvirt.org/page/Qemu_guest_agent
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20200513/280fd52a/attachment.htm>


More information about the libvirt-users mailing list