virsh autostart not working

root@virtual3:~# virsh autostart nstest
Domain nstest marked as autostarted

root@virtual3:~# virsh dominfo nstest 
Id:             -
Name:           nstest
UUID:           8cf691cd-7246-442b-a26b-3580e24600c5
OS Type:        hvm
State:          shut off
CPU(s):         2
Max memory:     6291456 KiB
Used memory:    2097152 KiB
Persistent:     yes
Autostart:      disable
Managed save:   no
Security model: apparmor
Security DOI:   0

root@virtual3:~# 

What am I doing wrong? The domain xml is listed in /etc/libvirt/qemu/autostart but still no autostart :(

Nothing in the logs :((

I was having the same problem (2/3/22) and found a solution now (2/7/22).

Problem: I was having the same problems too. It's never happened before. On one Centos 7 host, the first 3 VMs I had previously set to autostart was working fine (I could enable and disable autostart). But I had 4 others that had previously autostarted, now were set to not do so, and that I could not enable. I usually use the UI. If I click for autostart, save, and come back, it's not checked even though it should be. So I tried it per the command line it didn't work either and I discovered what you discovered above. Rebooting either the clients or the host machine makes no difference. Whether a client VM is running or shut off makes no difference.

Solution. It seems like something was getting out of sync. What, I'm not sure. The problem isn't apparently something saved in the virtual machine .xml file. While I never discovered exactly what was wrong, I did find figure out how to fix it. Anything set to autostart should have an entry in /etc/libvirt/qemu/autostart/ named something like machinename.xml containing a symbolic link to the virtual machine's xml configure file of the same name in /etc/libvirt/qemu/. Delete the symbolic link for the problematic clients in the /etc/libvirt/qemu/autostart directory (make sure you don’t delete the source xml in the qemu directory). Now when you try to turn on autostart either via the UI or with via ‘virsh autostart machinename’. I deleted the autostart/*xml files for the 4 problem clients, and then turned one on and off repeatedly via the UI, and the other 3 via the command line, and everything performs normal for me now...

In my case, the problem was that I had a file in the autostart folder and not a link.

root@kvm1630:/etc/libvirt/qemu # ls -l 
-rw------- 1 root root  7982 févr. 18 15:17 hebergement.xml

root@kvm1630:/etc/libvirt/qemu # ls -l autostart/
-rwx------ 1 root root 6195 avril 16  2021 hebergement.xml*

Solution: delete the file and create a symbolic link.

root@kvm1630:/etc/libvirt/qemu # rm autostart/hebergement.xml
rm: remove regular file 'autostart/hebergement.xml'? y

Then run the command again to make the VM autostart:

root@kvm1630:/etc/libvirt/qemu # virsh autostart hebergement
Domain hebergement marked as autostarted

root@kvm1630:/etc/libvirt/qemu # ls -l autostart/
lrwxrwxrwx 1 root root   33 févr. 18 15:49 hebergement.xml -> /etc/libvirt/qemu/hebergement.xml

We finally check that the VM is indeed autostart.

root@kvm1630:/etc/libvirt/qemu # virsh dominfo hebergement
Id:             9
Name:           hebergement
UUID:           74590197-8b3a-4bed-95e6-653ce7c456af
OS Type:        hvm
State:          running
CPU(s):         1
CPU time:       6614,7s
Max memory:     8388608 KiB
Used memory:    8388608 KiB
Persistent:     yes
Autostart:      enable
Managed save:   no
Security model: none
Security DOI:   0

FYI, I use fi-backup a LibVirtKvm-script to create VM snapshots every hour... Consequence: the VM definition xml file is changed every hour like so:

root@kvm1630:/etc/libvirt/qemu # colordiff hebergement.xml autostart/hebergement.xml
46,83c48
<       <source file='/var/lib/libvirt/images/hebergement.bimg-20220218-151710'/>
<       <backingStore type='file'>
<         <format type='qcow2'/>
<         <source file='/var/lib/libvirt/images/hebergement.bimg-20220218-141710'/>
<         <backingStore type='file'>
<           <format type='qcow2'/>
<           <source file='/var/lib/libvirt/images/hebergement.bimg-20220218-131710'/>
<           <backingStore type='file'>
<             <format type='qcow2'/>
<             <source file='/var/lib/libvirt/images/hebergement.bimg-20220218-121709'/>
<             <backingStore type='file'>
<               <format type='qcow2'/>
<               <source file='/var/lib/libvirt/images/hebergement.bimg-20220218-111709'/>
<               <backingStore type='file'>
<                 <format type='qcow2'/>
<                 <source file='/var/lib/libvirt/images/hebergement.bimg-20220218-101711'/>
<                 <backingStore type='file'>
<                   <format type='qcow2'/>
<                   <source file='/var/lib/libvirt/images/hebergement.bimg-20220218-091738'/>
<                   <backingStore type='file'>
<                     <format type='qcow2'/>
<                     <source file='/var/lib/libvirt/images/hebergement.bimg-20220218-091200'/>
<                     <backingStore type='file'>
<                       <format type='qcow2'/>
<                       <source file='/var/lib/libvirt/images/hebergement.bimg-20220218-082151'/>
<                       <backingStore type='file'>
<                         <format type='qcow2'/>
<                         <source file='/var/lib/libvirt/images/hebergement.qcow2'/>
<                         <backingStore/>
<                       </backingStore>
<                     </backingStore>
<                   </backingStore>
<                 </backingStore>
<               </backingStore>
<             </backingStore>
<           </backingStore>
<         </backingStore>
<       </backingStore>
---
>       <source file='/var/lib/libvirt/images/hebergement.bimg-20210415-011726'/>

hope it helps

Ernest.

It looks like you're expecting that setting 'autostart' will immediately start the VM. However, that's not the intended effect of autostart. Rather, it's solely there to ensure the VM starts automatically at boot time for the host. From the man page:

Configure a domain to be automatically started at boot.

If you then want to actually start the VM immediately, you need to do so with virsh start.