Unit libvirtd.service could not be found. on VM
Hi all, Some background: I recently has some issues with libvirt on my laptop when I got the error 'operation failed: pool 'default' already exists with uuid dd48b6ad-9a00-46eb-a3a4-c122d8a294a5' when I connected virt-manager. I was finally able to resolve it yesterday, when I removed libvirt and all its related content in /etc/libvirt, removed the pool by its UUID, deleted virbr0 & virbro-nic, removed the default network, reinstalled and created the network & default pool again Now I got libvirtd on my laptop up & running. However, when I install vms on my laptop, they don't have libvirtd.service This is the network configuration XML: <interface type="network"> <mac address="52:54:00:d0:40:69"/> <source network="default" portid="171a745c-f96d-412a-baa7-ee1feeaed6ac" bridge="virbr0"/> <target dev="vnet1"/> <model type="virtio"/> <alias name="net0"/> <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x0"/> </interface> I installed the vms with virt-manager. The Network source is Virtual network 'default': NAT I'm using CentOS8.1 on both my laptop & vms. Is there anything else I need to reconfigure or any thoughts why libvirtd.service doesn't exist on my VMS? Thanks, Dana
On Tue, May 12, 2020 at 01:00:06PM +0300, Dana Elfassy wrote:
Hi all, Some background: I recently has some issues with libvirt on my laptop when I got the error 'operation failed: pool 'default' already exists with uuid dd48b6ad-9a00-46eb-a3a4-c122d8a294a5' when I connected virt-manager. I was finally able to resolve it yesterday, when I removed libvirt and all its related content in /etc/libvirt, removed the pool by its UUID, deleted virbr0 & virbro-nic, removed the default network, reinstalled and created the network & default pool again
Now I got libvirtd on my laptop up & running.
However, when I install vms on my laptop, they don't have libvirtd.service This is the network configuration XML: <interface type="network"> <mac address="52:54:00:d0:40:69"/> <source network="default" portid="171a745c-f96d-412a-baa7-ee1feeaed6ac" bridge="virbr0"/> <target dev="vnet1"/> <model type="virtio"/> <alias name="net0"/> <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x0"/> </interface>
I installed the vms with virt-manager. The Network source is Virtual network 'default': NAT
I'm using CentOS8.1 on both my laptop & vms. Is there anything else I need to reconfigure or any thoughts why libvirtd.service doesn't exist on my VMS?
If the unit doesn't exist, then I suspect you are either missing the libvirt-daemon RPM or systemd has not correctly reloaded its unit files after install. (systemctl daemon-reload would fix the latter) Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Thanks, Daniel I verified I had libvirt-daemon rpm on my laptop and reloaded its units, but that didn't solve the issue. I then checked the vms- libvirt-daemon rpm was indeed missing on my vms. After I installed it & reloaded its unit files libvirtd.service was found, but as I started it, the error 'operation failed: pool 'default' already exists with uuid a42beb54-839e-437b-a48e-d06f6100205c' appeared again on my laptop. I'm not sure if I was supposed to install libvirt-daemon rpm on the vms? if it was needed - how do I resolve the error now? and any idea why it was missing? I never had to install it before if not - if you have any other thoughts/suggestions I'll be glad to hear :) Dana On Tue, May 12, 2020 at 1:16 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
Hi all, Some background: I recently has some issues with libvirt on my laptop when I got the error 'operation failed: pool 'default' already exists with uuid dd48b6ad-9a00-46eb-a3a4-c122d8a294a5' when I connected virt-manager. I was finally able to resolve it yesterday, when I removed libvirt and all its related content in /etc/libvirt, removed the pool by its UUID, deleted virbr0 & virbro-nic, removed the default network, reinstalled and created the network & default pool again
Now I got libvirtd on my laptop up & running.
However, when I install vms on my laptop, they don't have
On Tue, May 12, 2020 at 01:00:06PM +0300, Dana Elfassy wrote: libvirtd.service
This is the network configuration XML: <interface type="network"> <mac address="52:54:00:d0:40:69"/> <source network="default" portid="171a745c-f96d-412a-baa7-ee1feeaed6ac" bridge="virbr0"/> <target dev="vnet1"/> <model type="virtio"/> <alias name="net0"/> <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x0"/> </interface>
I installed the vms with virt-manager. The Network source is Virtual network 'default': NAT
I'm using CentOS8.1 on both my laptop & vms. Is there anything else I need to reconfigure or any thoughts why libvirtd.service doesn't exist on my VMS?
If the unit doesn't exist, then I suspect you are either missing the libvirt-daemon RPM or systemd has not correctly reloaded its unit files after install. (systemctl daemon-reload would fix the latter)
Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Tue, May 12, 2020 at 02:25:29PM +0300, Dana Elfassy wrote:
Thanks, Daniel I verified I had libvirt-daemon rpm on my laptop and reloaded its units, but that didn't solve the issue. I then checked the vms- libvirt-daemon rpm was indeed missing on my vms. After I installed it & reloaded its unit files libvirtd.service was found, but as I started it, the error 'operation failed: pool 'default' already exists with uuid a42beb54-839e-437b-a48e-d06f6100205c' appeared again on my laptop. I'm not sure if I was supposed to install libvirt-daemon rpm on the vms? if it was needed - how do I resolve the error now? and any idea why it was missing? I never had to install it before if not - if you have any other thoughts/suggestions I'll be glad to hear :)
If virt-manager is connecting to the host OS, there's no reason to install libvirtd in any guests VM. The error message is telling you that the 'default' storage pool already exists - "virsh pool-list" should show it. THe existance of this error message in the logs is not in itself a problem. It may just show that virt-manager is blindly trying to create the pool even when it already exists. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
if I understand correctly then I shouldn't have installed libvirt-daemon on the guests VMs? On Tue, May 12, 2020 at 2:34 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
On Tue, May 12, 2020 at 02:25:29PM +0300, Dana Elfassy wrote:
Thanks, Daniel I verified I had libvirt-daemon rpm on my laptop and reloaded its units, but that didn't solve the issue. I then checked the vms- libvirt-daemon rpm was indeed missing on my vms. After I installed it & reloaded its unit files libvirtd.service was found, but as I started it, the error 'operation failed: pool 'default' already exists with uuid a42beb54-839e-437b-a48e-d06f6100205c' appeared again on my laptop. I'm not sure if I was supposed to install libvirt-daemon rpm on the vms? if it was needed - how do I resolve the error now? and any idea why it was missing? I never had to install it before if not - if you have any other thoughts/suggestions I'll be glad to hear :)
If virt-manager is connecting to the host OS, there's no reason to install libvirtd in any guests VM.
The error message is telling you that the 'default' storage pool already exists - "virsh pool-list" should show it.
THe existance of this error message in the logs is not in itself a problem. It may just show that virt-manager is blindly trying to create the pool even when it already exists.
Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Tue, May 12, 2020 at 02:41:42PM +0300, Dana Elfassy wrote:
if I understand correctly then I shouldn't have installed libvirt-daemon on the guests VMs?
Correct Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
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
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@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
On 5/13/20 12:59 PM, Dana Elfassy wrote:
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
That sounds like a kickstart/distro problem. Libvirt itself does not guarantee it is installed by default on a distribution. Either you need to specify the correct group to install, or install packages yourself after the installation is done. Configuring what SW is installed inside guest is out of libvirt's scope, sorry. Michal
Thanks, I discovered I had wrong permissions for /var/lib/libvirt/qemu/, after setting them to drwxr-x--x. qemu qemu and executing daemon-reload libvirtd.service exists now on my vms :) However - I'm not able to get it to run. In the journal I see the message libvirtd[6800]: Unable to import CA certificate list /etc/pki/vdsm/certs/cacert.pem I have verified its permissions and that it's not empty. I also executed update-ca-trust, but still not able to start the service, any suggestions on this one? Dana On Wed, May 13, 2020 at 2:07 PM Michal Privoznik <mprivozn@redhat.com> wrote:
On 5/13/20 12:59 PM, Dana Elfassy wrote:
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
That sounds like a kickstart/distro problem. Libvirt itself does not guarantee it is installed by default on a distribution. Either you need to specify the correct group to install, or install packages yourself after the installation is done. Configuring what SW is installed inside guest is out of libvirt's scope, sorry.
Michal
Was able to solve this one as well Thanks for the kind and fast answers :) On Wed, May 13, 2020 at 3:32 PM Dana Elfassy <delfassy@redhat.com> wrote:
Thanks, I discovered I had wrong permissions for /var/lib/libvirt/qemu/, after setting them to drwxr-x--x. qemu qemu and executing daemon-reload libvirtd.service exists now on my vms :) However - I'm not able to get it to run. In the journal I see the message libvirtd[6800]: Unable to import CA certificate list /etc/pki/vdsm/certs/cacert.pem I have verified its permissions and that it's not empty. I also executed update-ca-trust, but still not able to start the service, any suggestions on this one? Dana
On Wed, May 13, 2020 at 2:07 PM Michal Privoznik <mprivozn@redhat.com> wrote:
On 5/13/20 12:59 PM, Dana Elfassy wrote:
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
That sounds like a kickstart/distro problem. Libvirt itself does not guarantee it is installed by default on a distribution. Either you need to specify the correct group to install, or install packages yourself after the installation is done. Configuring what SW is installed inside guest is out of libvirt's scope, sorry.
Michal
participants (3)
-
Dana Elfassy -
Daniel P. Berrangé -
Michal Privoznik