<div dir="ltr">Thanks, Michal,<div>On my laptop I do have libguestfs and libvirt-daemon-qemu. both libvirtd.service and libvirtd.socket are running ok on my laptop</div><div>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. </div><div>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?</div><div>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</div><div>Dana</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 13, 2020 at 12:26 PM Michal Privoznik <<a href="mailto:mprivozn@redhat.com">mprivozn@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 5/12/20 1:41 PM, Dana Elfassy wrote:<br>
> if I understand correctly then I shouldn't have installed libvirt-daemon <br>
> on the guests VMs?<br>
> <br>
> <br>
<br>
Just a little background to Daniel's response. Libvirt and QEMU treat <br>
guests as black boxes, to some extent. There are some exceptions to this <br>
rule, when it comes to para-virtualization (that is when the guest knows <br>
it is running virtualized and therefore can optimize some things). The <br>
perfect example is virtio (which are para-virtualized devices like NIC, <br>
disk, etc.). Depending on the guest the virtio drivers are either <br>
already installed (majority of Linux distributions including CentOS, if <br>
not all of them) or they have to be installed separately (Windows is <br>
typical example).<br>
<br>
Then, some tasks can be performed only if there is a small program <br>
running inside the guest (so called guest agent), which listens for <br>
incoming commands, executes them and sends the result back to libvirt. <br>
In CentOS this is qemu-guest-agent RPM. As mentioned, guest agent needs <br>
a channel to talk to libvirt which can be configured through virsh <br>
directly [1], or in virt-manager (if not already present, but I guess <br>
virt-install adds it automatically): Add hardware -> Channel -> Name: <br>
org.qemu.guest_agent.0 -> Finish.<br>
<br>
Some management applications have their own guest agents (e.g. <br>
libguestfs), but I wouldn't worry about them - the management <br>
application will configure them automatically; and you are not using <br>
them anyway.<br>
<br>
<br>
However, on the host the set of packages needed is different (note, you <br>
don't need any virtio drivers - they are contained in qemu already; nor <br>
you need the guest agent). libvirt-daemon-driver-qemu is the package <br>
containing qemu driver for libvirt. However, in order to use other <br>
features libvirt provides I suggest installing 'libvirt-daemon-kvm' <br>
which drags in the rest of packages (e.g. storage driver, network <br>
driver, etc.)<br>
<br>
The host is also where you need libvirtd running (systemctl enable <br>
libvirtd.service  or if you want to use socket activation then: <br>
systemctl enable libvirtd.socket)<br>
<br>
Michal<br>
<br>
<br>
1: <a href="https://wiki.libvirt.org/page/Qemu_guest_agent" rel="noreferrer" target="_blank">https://wiki.libvirt.org/page/Qemu_guest_agent</a><br>
<br>
</blockquote></div>