<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"> <div dir="ltr"> </div><blockquote type="cite"><div dir="ltr">Von: "Lentes, Bernd" <bernd.lentes@helmholtz-muenchen.de> Datum: 21. September 2020 um 18:38:48 MESZ An: Martin Kletzander <mkletzan@redhat.com> Betreff: Aw: can't define domain - error: cannot open /dev/null: Operation not permitted </div></blockquote><blockquote type="cite"><div dir="ltr"><title></title>Hi Martin, after configuring the logging and a restart of the service the problem dissapeared !?! Bernd Bernd Lentes > Am 21.09.2020 um 10:02 schrieb Martin Kletzander <mkletzan@redhat.com>: > > On Sun, Sep 20, 2020 at 01:09:51PM +0200, Lentes, Bernd wrote: >> Hi, >> > > Hi, I'll start with the usual... > >> i have a two-node cluster running on SLES 12 with pacemaker. >> The cluster refused to start the domains on one node. >> So i took some of the domains out of the cluster and tried to start it manually. >> This is what happened: >> >> virsh # define /mnt/share/vm_documents-oo.xml >> error: Failed to define domain from /mnt/share/vm_documents-oo.xml >> error: cannot open /dev/null: Operation not permitted >> >> Same with another domain. >> > > What does the XML look like? What do the logs[0] say? > >> On the other node domains are defined and started without problems. > > Are the configs (libvirtd.conf and qemu.conf) the same on both nodes? > > Have a nice day, > Martin > > [0] https://libvirt.org/kbase/debuglogs.html > >> Permissions on /dev and /dev/null are the same: >> >> ha-idg-1:/mnt/share # ll -d /dev >> drwxr-xr-x 25 root root 5420 Sep 17 20:47 /dev >> ha-idg-1:/mnt/share # ll /dev/null >> crw-rw-rw- 1 root root 1, 3 Aug 24 14:39 /dev/null >> >> ha-idg-2:/mnt/share # ll -d /dev >> drwxr-xr-x 25 root root 5340 Sep 9 10:31 /dev >> ha-idg-2:/mnt/share # ll /dev/null >> crw-rw-rw- 1 root root 1, 3 Aug 24 15:48 /dev/null >> >> ha-idg-1 is the one causing trouble. >> Both systems SLES 12 SP4, same patchlevel. >> livirt is: >> ha-idg-1:/mnt/share # rpm -qa|grep -i libvirt >> libvirt-daemon-driver-storage-iscsi-4.0.0-8.15.2.x86_64 >> libvirt-libs-4.0.0-8.15.2.x86_64 >> python-libvirt-python-4.0.0-2.34.x86_64 >> libvirt-daemon-driver-nwfilter-4.0.0-8.15.2.x86_64 >> libvirt-glib-1_0-0-0.2.1-1.2.x86_64 >> typelib-1_0-LibvirtGLib-1_0-0.2.1-1.2.x86_64 >> libvirt-admin-4.0.0-8.15.2.x86_64 >> libvirt-daemon-driver-storage-4.0.0-8.15.2.x86_64 >> libvirt-daemon-driver-storage-core-4.0.0-8.15.2.x86_64 >> libvirt-daemon-driver-storage-scsi-4.0.0-8.15.2.x86_64 >> libvirt-client-4.0.0-8.15.2.x86_64 >> libvirt-daemon-driver-nodedev-4.0.0-8.15.2.x86_64 >> libvirt-daemon-driver-storage-logical-4.0.0-8.15.2.x86_64 >> libvirt-daemon-driver-qemu-4.0.0-8.15.2.x86_64 >> libvirt-daemon-driver-secret-4.0.0-8.15.2.x86_64 >> libvirt-daemon-driver-storage-rbd-4.0.0-8.15.2.x86_64 >> libvirt-daemon-driver-interface-4.0.0-8.15.2.x86_64 >> libvirt-daemon-4.0.0-8.15.2.x86_64 >> libvirt-daemon-driver-network-4.0.0-8.15.2.x86_64 >> libvirt-daemon-driver-storage-mpath-4.0.0-8.15.2.x86_64 >> libvirt-daemon-qemu-4.0.0-8.15.2.x86_64 >> libvirt-daemon-config-network-4.0.0-8.15.2.x86_64 >> libvirt-daemon-driver-storage-disk-4.0.0-8.15.2.x86_64 >> >> Any ideas ? >> Maybe a restart would help, but it's Linux, not Windows ... >> I'd like to understand what's going wrong. >> >> Thanks. >> >> >> Bernd >> -- >> >> Bernd Lentes >> Systemadministration >> Institute for Metabolism and Cell Death (MCD) >> Building 25 - office 122 >> HelmholtzZentrum München >> bernd.lentes@helmholtz-muenchen.de >> phone: +49 89 3187 1241 >> phone: +49 89 3187 3827 >> fax: +49 89 3187 2294 >> http://www.helmholtz-muenchen.de/mcd >> >> stay healthy >> Helmholtz Zentrum MÃ¼nchen >> >> Helmholtz Zentrum MÃ¼nchen >> >> </div></blockquote> Helmholtz Zentrum München Helmholtz Zentrum München </body></html>