

The loginctl command was obtained from this answer.
Kvm reboot guest time zone changes how to#
In the case of Ubuntu 20.04.1 installing QEMU/KVM with apt-get did automatically start all services, and ended up resolving strictly by finding out how to give the user running Virtual Machine Manager libvirt group access (even though /etc/group did show that the user was granted the rights).Īs others mention, logout/login is usually necessary to register new group permissions, but, in the case of a GNOME graphical desktop using gdm, logout and re-login were not sufficient to grant the GUI user new libvirt group rights. Various answers allude to the fact that the problem can occur due to group permissions not getting applied to the user running Virtual Machine Manager, and, the accepted answer, noting that reboot fixed the problem, quite possibly depended on reboot to give the user the group permissions on login (though reboot could potentially start services also). LibvirtError: Failed to connect socket to '/var/run/libvirt/libvirt-sock': Permission denied If ret is None:raise libvirtError('virConnectOpenAuth() failed') Output of getent group libvirtd: libvirtd:x:130:OTHERUSER,MYUSERĭetailed error message Unable to connect to libvirt.įailed to connect socket to '/var/run/libvirt/libvirt-sock': Permission deniedįile "/usr/share/virt-manager/virtManager/connection.py", line 1185, in _open_threadįile "/usr/share/virt-manager/virtManager/connection.py", line 1167, in _try_openįile "/usr/lib/python2.7/dist-packages/libvirt.py", line 102, in openAuth Srwxrwx- 1 root libvirtd 0 Set 13 15:04 /var/run/libvirt/libvirt-sock Output of ls -l /var/run/libvirt/libvirt-sock: Output of ps ax | grep libvirt: 9225 ? Sl 0:04 /usr/sbin/libvirtd -dĩ302 ? S 0:00 /usr/sbin/dnsmasq -u libvirt-dnsmasq -strict-order -bind-interfaces -pid-file=/var/run/libvirt/network/default.pid -conf-file= -except-interface lo -listen-address 192.168.122.1 -dhcp-range 192.168.122.2,192.168.122.254 -dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases -dhcp-lease-max=253 -dhcp-no-override` I don't know how to check for the daemon.I added the -utc option to the kickstart timezone option and it solved this issue.The error doesn't show up if I start gksudo virt-manager. The guest was created using a kickstart file which by default doesn't set the hardware clock on UTC time. The answer by Michael Hampton below solved the problem.
Kvm reboot guest time zone changes software#
The output is a little clearer though because the software and hardware clocks are set with the same time. I set the hardware clock to use local time using the -localtime option on the hwclock command. I've run dmesg | grep kvm-clock on the guest and it confirmed kvm clock is in use.There is a good discussion of this in KVM guests clock synchronisation, which suggests that kvm-clock running in the guest should take care of this. I've considered using a time server to resolve the issue, but Ubuntu recommends not using NTP on the KVM guests.One of the kvm hosts is running Ubuntu 11.04 and the same behaviour happened.I tried this on three separate physical servers all exhibit the same exact behaviour.Once the time is corrected on the guests then they can be rebooted without the time shifting incorrectly. The output below shows the system time and hardware clock time on the host and guest. If however the KVM host is rebooted (the host has no time issues between reboots), then once I start my KVM guests all of them are exactly 3 hours behind the correct time. After setting the time correctly in the guests using date -s I am able to reboot the guests as much as I like with the correct time being retained between reboots. The servers are in the AST time zone which is UTC + 3 hours. I have installed Ubuntu server 12.04 as a KVM host, and created an Ubuntu guest that is also running Ubuntu server 12.04.
