On 2/17/20 8:20 PM, Yuri Weinstein wrote:
Thanks Michal!
See comments in line
On Mon, Feb 17, 2020 at 9:23 AM Michal Privoznik <mprivozn@xxxxxxxxxx
<mailto:mprivozn@xxxxxxxxxx>> wrote:
On 2/16/20 10:20 PM, Yuri Weinstein wrote:
> I used to have QEMU/KVM and Virtual Machine Manager running on
ubuntu
> 16.04 and used to start my VM from crontab as:
>
> @reboot sleep 30 && virsh start WINDOWS10
Libvirt has an autostart feature, which can start your domain on the
first time libvirtd is started (i.e. during boot).
virsh autostart WINDOWS10
>
> After upgrading to ubuntu 18.04 this stopped working, with error:
>
> error: failed to get domain 'WINDOWS10'
> error: Domain not found: no domain with matching name 'WINDOWS10'
>
> Running command as "virsh start WINDOWS10" works fine.
>
This is probably because cron doesn't run the command as root and hence
the virsh is no longer connecting to 'qemu:///system' but
'qemu:///session'. Change it to:
virsh -c qemu:///system start WINDOWS10
I managed to force austart via Startup App as:
sh -c "sleep 30 && /usr/bin/virsh start WINDOWS10"
See your point about using root and/or 'qemu:///system' and will try it.
But I suggest using the autostart feature instead.
This is the main issue - it does not work! :( Tried via command line and UI
You can see =>
Autostart: enable
How can this be fixed and/or troubleshooted?
Oh, I've completely missed that. Sorry. What is your libvirt version?
Since v5.9.0 libvirt will autostart domains exactly once for every boot
of the host. I mean, when libvirtd is started it will check if
/var/run/libvirt/qemu/autostarted file exists and if it doesn't, it will
autostart all qemu domains with autostart enabled. If the file does
exist then no autostart is attempted.
This usually works as expected - when host boots and starts libvirtd
service all domains are autostarted. And if libvirtd is restarted
afterwards no autostart is happening. If host reboots, /var/run should
be purged and the file with it. Therefore, autostart will be run after
reboot again.
Under what connection does your domain live? qemu:///system or
qemu:///session? Because if it is the latter then this won't work -
session daemon is not started automatically. However, if you are using
socket activated system daemon, then the daemon is not started on the
boot only on its first use and therefore autostart will be delayed until
then.
Michal