[libvirt-users] "virsh list --all" is intermittently causing a shutdown client to boot?
Hello, I have a CentOS 7 client running on a CentOS 7 server. "virsh --version" reports that 3.9.0 is being used. I'm issuing a "virsh shutdown" command to shutdown the client. I then confirm that the client has actually shutdown using "virsh list --all". Lately I've been seeing instances where I shutdown the client, turn away to work on something else, and then turn back to find that the client has booted again. Initially I thought I was mistaken, and that I somehow hadn't properly shutdown the client, but further experimentation shows that's definitely not the case. I've been able to reproduce this repeatedly using the following steps. 1. Run "virsh shutdown CLIENT"2. Wait ~30-60 seconds3. Run "virsh list --all; virsh console CLIENT" If I run "virsh console CLIENT" on its own when the client is in a shutdown state, I get the expected "error: The domain is not running" message. If I omit step #2 and run step #3 immediately after shutting down the client, virsh also complains that the client's not started and refuses to open a console. However, if I add a pause -- step 2, above -- between the shutdown and the "list --all" commands, then "list --all" shows that the client is running, and a console is opened to the VM. I have confirmed that the client boot is definitely being started by the "list --all" command (and not being started by something else while I'm not looking) by combining the "list --all" and "console" commands in step 3. This is ensuring that the console is started as soon as the "list --all" is complete, and the resulting screen output shows the BIOS boot options quickly followed by the kernel boot messages being dumped to the console. I can watch the entire boot process from start to finish. That pause between the shutdown and the "list --all" is critical. I've shutdown the client and then immediately followed it up with the command: watch virsh list --all ...which will run the "list --all" command every 2 seconds. This will run indefinitely without triggering the boot, which eliminates the possibility of the boot occurring due to the amount of time since the shutdown. It may be that other virsh commands are also causing the client to boot, but thus far I've only reproduced it using the list --all command. Can anyone tell me why this is happening? A bug? Something in my config? Something else? Thanks in advance, -peter .
On Tue, Dec 11, 2018 at 14:39:40 +0000, Peter Kukla wrote:
Hello, I have a CentOS 7 client running on a CentOS 7 server. "virsh --version" reports that 3.9.0 is being used. I'm issuing a "virsh shutdown" command to shutdown the client. I then confirm that the client has actually shutdown using "virsh list --all". Lately I've been seeing instances where I shutdown the client, turn away to work on something else, and then turn back to find that the client has booted again. Initially I thought I was mistaken, and that I somehow hadn't properly shutdown the client, but further experimentation shows that's definitely not the case. I've been able to reproduce this repeatedly using the following steps. 1. Run "virsh shutdown CLIENT"2. Wait ~30-60 seconds3. Run "virsh list --all; virsh console CLIENT" If I run "virsh console CLIENT" on its own when the client is in a shutdown state, I get the expected "error: The domain is not running" message. If I omit step #2 and run step #3 immediately after shutting down the client, virsh also complains that the client's not started and refuses to open a console. However, if I add a pause -- step 2, above -- between the shutdown and the "list --all" commands, then "list --all" shows that the client is running, and a console is opened to the VM. I have confirmed that the client boot is definitely being started by the "list --all" command (and not being started by something else while I'm not looking) by combining the "list --all" and "console" commands in step 3. This is ensuring that the console is started as soon as the "list --all" is complete, and the resulting screen output shows the BIOS boot options quickly followed by the kernel boot messages being dumped to the console. I can watch the entire boot process from start to finish. That pause between the shutdown and the "list --all" is critical. I've shutdown the client and then immediately followed it up with the command: watch virsh list --all ...which will run the "list --all" command every 2 seconds. This will run indefinitely without triggering the boot, which eliminates the possibility of the boot occurring due to the amount of time since the shutdown. It may be that other virsh commands are also causing the client to boot, but thus far I've only reproduced it using the list --all command. Can anyone tell me why this is happening? A bug? Something in my config? Something else? Thanks in advance,
This is indeed very strange and we would need to look at the logs to check what's going on. Could you follow the steps in https://wiki.libvirt.org/page/DebugLogs#Runtime_setting to enable debug logs for libvirtd and share the (compressed) libvirtd.log somewhere? Jirka
The /etc/libvirt/libvirtd.conf file was modified to include the following: log_level = 1 log_filters="3:remote 4:event 3:json 3:rpc" log_outputs="1:file:/var/log/libvirt/libvirtd.log" The service was then restarted, and I ran "tail -f" against the log to determine exactly which entries were being created as a result of specific actions on my part. I then reproduced the error. I ran "virsh console proxy2" expecting it to tell me whether the VM was running, and that resulted in the VM booting. (So it's not just "list --all" that's causing the unexpected boots.) That resulted in the following chunk of data being written to the log: 2018-12-12 18:47:57.361+0000: 21264: debug : virNetlinkEventCallback:707 : dispatching to max 0 clients, called from event watch 72018-12-12 18:47:57.361+0000: 21264: debug : virNetlinkEventCallback:720 : event not handled.2018-12-12 18:47:57.361+0000: 21264: debug : virNetlinkEventCallback:707 : dispatching to max 0 clients, called from event watch 72018-12-12 18:47:57.361+0000: 21264: debug : virNetlinkEventCallback:720 : event not handled.2018-12-12 18:47:57.361+0000: 21264: debug : virNetlinkEventCallback:707 : dispatching to max 0 clients, called from event watch 72018-12-12 18:47:57.361+0000: 21264: debug : virNetlinkEventCallback:720 : event not handled.2018-12-12 18:47:57.373+0000: 21323: debug : udevHandleOneDevice:1677 : udev action: 'add'2018-12-12 18:47:57.373+0000: 21323: debug : udevGetDeviceProperty:149 : Found property key 'DRIVER' value '<null>' for device with sysname 'tap3'2018-12-12 18:47:57.374+0000: 21323: debug : udevGetDeviceProperty:149 : Found property key 'SUBSYSTEM' value 'net' for device with sysname 'tap3'2018-12-12 18:47:57.374+0000: 21323: debug : udevGetDeviceProperty:149 : Found property key 'INTERFACE' value 'tap3' for device with sysname 'tap3'2018-12-12 18:47:57.374+0000: 21323: debug : udevGetDeviceSysfsAttr:217 : Found sysfs attribute 'address' value 'fe:52:16:f6:1a:8d' for device with sysname 'tap3'2018-12-12 18:47:57.374+0000: 21323: debug : udevGetDeviceSysfsAttr:217 : Found sysfs attribute 'addr_len' value '6' for device with sysname 'tap3'2018-12-12 18:47:57.374+0000: 21323: debug : virFileClose:110 : Closed fd 292018-12-12 18:47:57.375+0000: 21323: debug : virPCIGetDeviceAddressFromSysfsLink:2624 : '/sys/class/net/tap3/device' does not exist2018-12-12 18:47:57.375+0000: 21323: debug : virFileClose:110 : Closed fd 292018-12-12 18:47:57.375+0000: 21323: info : virObjectNew:254 : OBJECT_NEW: obj=0x7f39f8001f70 classname=virNodeDeviceObj2018-12-12 18:47:57.375+0000: 21323: info : virObjectRef:388 : OBJECT_REF: obj=0x7f39f8001f702018-12-12 18:47:57.375+0000: 21323: info : virObjectNew:254 : OBJECT_NEW: obj=0x7f39f8002030 classname=virNodeDeviceEventLifecycle2018-12-12 18:47:57.375+0000: 21323: info : virObjectUnref:350 : OBJECT_UNREF: obj=0x7f39f8001f702018-12-12 18:47:57.375+0000: 21323: info : virObjectUnref:350 : OBJECT_UNREF: obj=0x7f39f80020302018-12-12 18:47:57.375+0000: 21323: info : virObjectUnref:352 : OBJECT_DISPOSE: obj=0x7f39f80020302018-12-12 18:47:57.375+0000: 21323: debug : udevHandleOneDevice:1677 : udev action: 'add'2018-12-12 18:47:57.375+0000: 21323: debug : udevGetDeviceProperty:149 : Found property key 'DRIVER' value '<null>' for device with sysname 'rx-0'2018-12-12 18:47:57.375+0000: 21323: debug : udevGetDeviceProperty:149 : Found property key 'SUBSYSTEM' value 'queues' for device with sysname 'rx-0'2018-12-12 18:47:57.375+0000: 21323: debug : udevGetDeviceType:1349 : Could not determine device type for device with sysfs name 'rx-0'2018-12-12 18:47:57.375+0000: 21323: debug : udevAddOneDevice:1541 : Discarding device -1 0x7f39f8001900 /sys/devices/virtual/net/tap3/queues/rx-02018-12-12 18:47:57.375+0000: 21323: debug : udevHandleOneDevice:1677 : udev action: 'add'2018-12-12 18:47:57.375+0000: 21323: debug : udevGetDeviceProperty:149 : Found property key 'DRIVER' value '<null>' for device with sysname 'tx-0'2018-12-12 18:47:57.375+0000: 21323: debug : udevGetDeviceProperty:149 : Found property key 'SUBSYSTEM' value 'queues' for device with sysname 'tx-0'2018-12-12 18:47:57.375+0000: 21323: debug : udevGetDeviceType:1349 : Could not determine device type for device with sysfs name 'tx-0'2018-12-12 18:47:57.375+0000: 21323: debug : udevAddOneDevice:1541 : Discarding device -1 0x7f39f8001900 /sys/devices/virtual/net/tap3/queues/tx-02018-12-12 18:47:57.460+0000: 21264: debug : virNetlinkEventCallback:707 : dispatching to max 0 clients, called from event watch 72018-12-12 18:47:57.460+0000: 21264: debug : virNetlinkEventCallback:720 : event not handled.2018-12-12 18:47:57.464+0000: 21323: debug : udevHandleOneDevice:1677 : udev action: 'change'2018-12-12 18:47:57.464+0000: 21323: debug : udevGetDeviceProperty:149 : Found property key 'DRIVER' value '<null>' for device with sysname 'kvm'2018-12-12 18:47:57.464+0000: 21323: debug : udevGetDeviceProperty:149 : Found property key 'SUBSYSTEM' value 'misc' for device with sysname 'kvm'2018-12-12 18:47:57.464+0000: 21323: debug : udevGetDeviceType:1349 : Could not determine device type for device with sysfs name 'kvm'2018-12-12 18:47:57.464+0000: 21323: debug : udevAddOneDevice:1541 : Discarding device -1 0x7f39f8001900 /sys/devices/virtual/misc/kvm I then ran "virsh shutdown proxy2" to stop the VM, resulting in the following log output: 2018-12-12 18:49:24.556+0000: 21264: debug : virNetlinkEventCallback:707 : dispatching to max 0 clients, called from event watch 72018-12-12 18:49:24.556+0000: 21264: debug : virNetlinkEventCallback:720 : event not handled.2018-12-12 18:49:24.556+0000: 21264: debug : virNetlinkEventCallback:707 : dispatching to max 0 clients, called from event watch 72018-12-12 18:49:24.556+0000: 21264: debug : virNetlinkEventCallback:720 : event not handled.2018-12-12 18:49:24.556+0000: 21264: debug : virNetlinkEventCallback:707 : dispatching to max 0 clients, called from event watch 72018-12-12 18:49:24.556+0000: 21264: debug : virNetlinkEventCallback:720 : event not handled.2018-12-12 18:49:24.561+0000: 21323: debug : udevHandleOneDevice:1677 : udev action: 'remove'2018-12-12 18:49:24.561+0000: 21323: debug : udevRemoveOneDevice:1409 : Failed to find device to remove that has udev name '/sys/devices/virtual/net/tap3/queues/tx-0'2018-12-12 18:49:24.561+0000: 21323: debug : udevHandleOneDevice:1677 : udev action: 'remove'2018-12-12 18:49:24.562+0000: 21323: debug : udevRemoveOneDevice:1409 : Failed to find device to remove that has udev name '/sys/devices/virtual/net/tap3/queues/rx-0'2018-12-12 18:49:24.562+0000: 21323: debug : udevHandleOneDevice:1677 : udev action: 'remove'2018-12-12 18:49:24.562+0000: 21323: info : virObjectRef:388 : OBJECT_REF: obj=0x7f39f8001f702018-12-12 18:49:24.562+0000: 21323: info : virObjectNew:254 : OBJECT_NEW: obj=0x7f39f80016f0 classname=virNodeDeviceEventLifecycle2018-12-12 18:49:24.562+0000: 21323: debug : udevRemoveOneDevice:1419 : Removing device 'net_tap3_fe_52_16_f6_1a_8d' with sysfs path '/sys/devices/virtual/net/tap3'2018-12-12 18:49:24.562+0000: 21323: info : virObjectRef:388 : OBJECT_REF: obj=0x7f39f8001f702018-12-12 18:49:24.562+0000: 21323: info : virObjectUnref:350 : OBJECT_UNREF: obj=0x7f39f8001f702018-12-12 18:49:24.563+0000: 21323: info : virObjectUnref:350 : OBJECT_UNREF: obj=0x7f39f8001f702018-12-12 18:49:24.563+0000: 21323: info : virObjectUnref:350 : OBJECT_UNREF: obj=0x7f39f8001f702018-12-12 18:49:24.563+0000: 21323: info : virObjectUnref:352 : OBJECT_DISPOSE: obj=0x7f39f8001f702018-12-12 18:49:24.563+0000: 21323: info : virObjectUnref:350 : OBJECT_UNREF: obj=0x7f39f80016f02018-12-12 18:49:24.563+0000: 21323: info : virObjectUnref:352 : OBJECT_DISPOSE: obj=0x7f39f80016f02018-12-12 18:49:24.633+0000: 21264: debug : virNetlinkEventCallback:707 : dispatching to max 0 clients, called from event watch 72018-12-12 18:49:24.633+0000: 21264: debug : virNetlinkEventCallback:720 : event not handled.2018-12-12 18:49:24.646+0000: 21323: debug : udevHandleOneDevice:1677 : udev action: 'change'2018-12-12 18:49:24.646+0000: 21323: debug : udevGetDeviceProperty:149 : Found property key 'DRIVER' value '<null>' for device with sysname 'kvm'2018-12-12 18:49:24.648+0000: 21323: debug : udevGetDeviceProperty:149 : Found property key 'SUBSYSTEM' value 'misc' for device with sysname 'kvm'2018-12-12 18:49:24.648+0000: 21323: debug : udevGetDeviceType:1349 : Could not determine device type for device with sysfs name 'kvm'2018-12-12 18:49:24.648+0000: 21323: debug : udevAddOneDevice:1541 : Discarding device -1 0x7f39f8001560 /sys/devices/virtual/misc/kvm I then ran "watch virsh list --all" for 10 minutes, and it continuously showed the VM in a "shut off" state. Next I ran "virsh console proxy2" and "virsh list --all" immediately after killing the "watch" process, and it dumped the following output to the screen: [pkukla@vs2 ~]$ virsh console proxy2error: The domain is not running [pkukla@vs2 ~]$ virsh list --all Id Name State---------------------------------------------------- - proxy2 shut off - proxy2-clone shut off Then I waited ~2-3 minutes and ran "virsh list --all" again, and it caused the VM to boot: [pkukla@vs2 ~]$ virsh list --all Id Name State---------------------------------------------------- 1 proxy2 running - proxy2-clone shut off The debug output from the log corresponding to this boot sequence: 2018-12-12 19:03:53.712+0000: 21264: debug : virNetlinkEventCallback:707 : dispatching to max 0 clients, called from event watch 72018-12-12 19:03:53.712+0000: 21264: debug : virNetlinkEventCallback:720 : event not handled.2018-12-12 19:03:53.712+0000: 21264: debug : virNetlinkEventCallback:707 : dispatching to max 0 clients, called from event watch 72018-12-12 19:03:53.712+0000: 21264: debug : virNetlinkEventCallback:720 : event not handled.2018-12-12 19:03:53.713+0000: 21264: debug : virNetlinkEventCallback:707 : dispatching to max 0 clients, called from event watch 72018-12-12 19:03:53.713+0000: 21264: debug : virNetlinkEventCallback:720 : event not handled.2018-12-12 19:03:53.723+0000: 21323: debug : udevHandleOneDevice:1677 : udev action: 'add'2018-12-12 19:03:53.723+0000: 21323: debug : udevGetDeviceProperty:149 : Found property key 'DRIVER' value '<null>' for device with sysname 'tap3'2018-12-12 19:03:53.724+0000: 21323: debug : udevGetDeviceProperty:149 : Found property key 'SUBSYSTEM' value 'net' for device with sysname 'tap3'2018-12-12 19:03:53.724+0000: 21323: debug : udevGetDeviceProperty:149 : Found property key 'INTERFACE' value 'tap3' for device with sysname 'tap3'2018-12-12 19:03:53.724+0000: 21323: debug : udevGetDeviceSysfsAttr:217 : Found sysfs attribute 'address' value 'fe:c9:eb:76:37:d8' for device with sysname 'tap3'2018-12-12 19:03:53.724+0000: 21323: debug : udevGetDeviceSysfsAttr:217 : Found sysfs attribute 'addr_len' value '6' for device with sysname 'tap3'2018-12-12 19:03:53.724+0000: 21323: debug : virFileClose:110 : Closed fd 292018-12-12 19:03:53.725+0000: 21323: debug : virPCIGetDeviceAddressFromSysfsLink:2624 : '/sys/class/net/tap3/device' does not exist2018-12-12 19:03:53.725+0000: 21323: debug : virFileClose:110 : Closed fd 292018-12-12 19:03:53.725+0000: 21323: info : virObjectNew:254 : OBJECT_NEW: obj=0x7f39f8001760 classname=virNodeDeviceObj2018-12-12 19:03:53.725+0000: 21323: info : virObjectRef:388 : OBJECT_REF: obj=0x7f39f80017602018-12-12 19:03:53.725+0000: 21323: info : virObjectNew:254 : OBJECT_NEW: obj=0x7f39f80017d0 classname=virNodeDeviceEventLifecycle2018-12-12 19:03:53.725+0000: 21323: info : virObjectUnref:350 : OBJECT_UNREF: obj=0x7f39f80017602018-12-12 19:03:53.725+0000: 21323: info : virObjectUnref:350 : OBJECT_UNREF: obj=0x7f39f80017d02018-12-12 19:03:53.725+0000: 21323: info : virObjectUnref:352 : OBJECT_DISPOSE: obj=0x7f39f80017d02018-12-12 19:03:53.725+0000: 21323: debug : udevHandleOneDevice:1677 : udev action: 'add'2018-12-12 19:03:53.725+0000: 21323: debug : udevGetDeviceProperty:149 : Found property key 'DRIVER' value '<null>' for device with sysname 'tx-0'2018-12-12 19:03:53.725+0000: 21323: debug : udevGetDeviceProperty:149 : Found property key 'SUBSYSTEM' value 'queues' for device with sysname 'tx-0'2018-12-12 19:03:53.725+0000: 21323: debug : udevGetDeviceType:1349 : Could not determine device type for device with sysfs name 'tx-0'2018-12-12 19:03:53.725+0000: 21323: debug : udevAddOneDevice:1541 : Discarding device -1 0x7f39f8001f60 /sys/devices/virtual/net/tap3/queues/tx-02018-12-12 19:03:53.725+0000: 21323: debug : udevHandleOneDevice:1677 : udev action: 'add'2018-12-12 19:03:53.725+0000: 21323: debug : udevGetDeviceProperty:149 : Found property key 'DRIVER' value '<null>' for device with sysname 'rx-0'2018-12-12 19:03:53.725+0000: 21323: debug : udevGetDeviceProperty:149 : Found property key 'SUBSYSTEM' value 'queues' for device with sysname 'rx-0'2018-12-12 19:03:53.725+0000: 21323: debug : udevGetDeviceType:1349 : Could not determine device type for device with sysfs name 'rx-0'2018-12-12 19:03:53.725+0000: 21323: debug : udevAddOneDevice:1541 : Discarding device -1 0x7f39f8001f60 /sys/devices/virtual/net/tap3/queues/rx-02018-12-12 19:03:53.800+0000: 21264: debug : virNetlinkEventCallback:707 : dispatching to max 0 clients, called from event watch 72018-12-12 19:03:53.800+0000: 21264: debug : virNetlinkEventCallback:720 : event not handled.2018-12-12 19:03:53.804+0000: 21323: debug : udevHandleOneDevice:1677 : udev action: 'change'2018-12-12 19:03:53.804+0000: 21323: debug : udevGetDeviceProperty:149 : Found property key 'DRIVER' value '<null>' for device with sysname 'kvm'2018-12-12 19:03:53.804+0000: 21323: debug : udevGetDeviceProperty:149 : Found property key 'SUBSYSTEM' value 'misc' for device with sysname 'kvm'2018-12-12 19:03:53.804+0000: 21323: debug : udevGetDeviceType:1349 : Could not determine device type for device with sysfs name 'kvm'2018-12-12 19:03:53.804+0000: 21323: debug : udevAddOneDevice:1541 : Discarding device -1 0x7f39f8001f60 /sys/devices/virtual/misc/kvm I then disabled logging and restarted the service. I've been doing has been under my personal account ("pkukla") on the server. The "root" account has production instances, so I have not been working under that account because I don't want to break anything. In fact, I had only noticed this and reproduced it while working in my personal account, and I originally wasn't sure that it was happening with any other user accounts. While collecting this data, however, I am reasonably sure that I managed to boot one of the VMs in the "root" account with this bug. I didn't monitor the VM in the same way that I've been monitoring the bug in my own account, but a server that shouldn't have been booted did boot around the time that I was working on the server as "root", and I've confirmed with the other people with the appropriate privileges to login as "root", and none of them started the VM. The VM in the "root" userspace that was booted was the "slo_redmine" VM. I do not know whether it was booted during the time that logging was enabled, so maybe that is reflected in the log, also? If I *did* managed to repro the bug while working as "root", then this implies something else: This is apparently only affecting VM's in the user's on environment. For example, I've been reproducing the trigger conditions frequently over the past few days to diagnose this, but all of my testing as user "pkukla" does NOT seem to have affected the VMs in the "root" user space. I'm not willing to guarantee that the effects of this are only confined to a user's own VMs because I haven't exhaustively tested the theory, but it seems likely that's the case. The full log has been provided to you as a link in another email. Please let me know if you have any questions, and thanks again for looking at this! Peter Kukla On Wednesday, December 12, 2018, 2:19:10 AM EST, Jiri Denemark <jdenemar@redhat.com> wrote: On Tue, Dec 11, 2018 at 14:39:40 +0000, Peter Kukla wrote:
Hello, I have a CentOS 7 client running on a CentOS 7 server. "virsh --version" reports that 3.9.0 is being used. I'm issuing a "virsh shutdown" command to shutdown the client. I then confirm that the client has actually shutdown using "virsh list --all". Lately I've been seeing instances where I shutdown the client, turn away to work on something else, and then turn back to find that the client has booted again. Initially I thought I was mistaken, and that I somehow hadn't properly shutdown the client, but further experimentation shows that's definitely not the case. I've been able to reproduce this repeatedly using the following steps. 1. Run "virsh shutdown CLIENT"2. Wait ~30-60 seconds3. Run "virsh list --all; virsh console CLIENT" If I run "virsh console CLIENT" on its own when the client is in a shutdown state, I get the expected "error: The domain is not running" message. If I omit step #2 and run step #3 immediately after shutting down the client, virsh also complains that the client's not started and refuses to open a console. However, if I add a pause -- step 2, above -- between the shutdown and the "list --all" commands, then "list --all" shows that the client is running, and a console is opened to the VM. I have confirmed that the client boot is definitely being started by the "list --all" command (and not being started by something else while I'm not looking) by combining the "list --all" and "console" commands in step 3. This is ensuring that the console is started as soon as the "list --all" is complete, and the resulting screen output shows the BIOS boot options quickly followed by the kernel boot messages being dumped to the console. I can watch the entire boot process from start to finish. That pause between the shutdown and the "list --all" is critical. I've shutdown the client and then immediately followed it up with the command: watch virsh list --all ...which will run the "list --all" command every 2 seconds. This will run indefinitely without triggering the boot, which eliminates the possibility of the boot occurring due to the amount of time since the shutdown. It may be that other virsh commands are also causing the client to boot, but thus far I've only reproduced it using the list --all command. Can anyone tell me why this is happening? A bug? Something in my config? Something else? Thanks in advance,
This is indeed very strange and we would need to look at the logs to check what's going on. Could you follow the steps in https://wiki.libvirt.org/page/DebugLogs#Runtime_setting to enable debug logs for libvirtd and share the (compressed) libvirtd.log somewhere? Jirka
On 12/11/18 3:39 PM, Peter Kukla wrote:
Hello, <snip/>
Could it be that the domain is set as "autostart"? The session daemon is slightly different to system daemon. The former come and go if there is no activity for (by default) 30 seconds. And if the domain would be marked as 'autostart' (meaning start the domain automatically when the daemon is being started) the I could imagine this happening. `virsh dominfo $domain' should tell you that. Michal
Autostart is set to "enable" for this domain, but I wouldn't expect autostart to be invoked when a simple "read-only" command is run. I'd expect the "list --all" command to only display details about the domain...not change the status of the domain by booting it. Maybe I'm misunderstanding things... On Thursday, December 13, 2018, 11:20:30 AM EST, Michal Privoznik <mprivozn@redhat.com> wrote: On 12/11/18 3:39 PM, Peter Kukla wrote:
Hello, <snip/>
Could it be that the domain is set as "autostart"? The session daemon is slightly different to system daemon. The former come and go if there is no activity for (by default) 30 seconds. And if the domain would be marked as 'autostart' (meaning start the domain automatically when the daemon is being started) the I could imagine this happening. `virsh dominfo $domain' should tell you that. Michal
On 12/14/18 4:31 PM, Peter Kukla wrote:
Autostart is set to "enable" for this domain, but I wouldn't expect autostart to be invoked when a simple "read-only" command is run. I'd expect the "list --all" command to only display details about the domain...not change the status of the domain by booting it. Maybe I'm misunderstanding things...
Bingo! I mean, this is still a bug, but not that trivial to fix. As I explained earlier, in session mode the daemon is shut off after some time of inactivity. Then, when there is some new activity the daemon is started up again, but it has no idea about the previous state of things, i.e. you shut down a domain and want it keep shut down. All it knows is that there is a domain with autostart set that is not running. So it starts the domain again. The only solution I see is to disable autostart for session URI. As a workaround you can start session daemon yourself (just run libvirtd as regular user of yours). This way the daemon is not autostarted automatically and therefore without --timeout. Michal
That makes sense. Now that I understand what's going on, I can work around it. Thanks for the explanation. -peter On Friday, December 14, 2018, 3:28:32 PM EST, Michal Prívozník <mprivozn@redhat.com> wrote: On 12/14/18 4:31 PM, Peter Kukla wrote:
Autostart is set to "enable" for this domain, but I wouldn't expect autostart to be invoked when a simple "read-only" command is run. I'd expect the "list --all" command to only display details about the domain...not change the status of the domain by booting it. Maybe I'm misunderstanding things...
Bingo! I mean, this is still a bug, but not that trivial to fix. As I explained earlier, in session mode the daemon is shut off after some time of inactivity. Then, when there is some new activity the daemon is started up again, but it has no idea about the previous state of things, i.e. you shut down a domain and want it keep shut down. All it knows is that there is a domain with autostart set that is not running. So it starts the domain again. The only solution I see is to disable autostart for session URI. As a workaround you can start session daemon yourself (just run libvirtd as regular user of yours). This way the daemon is not autostarted automatically and therefore without --timeout. Michal
participants (4)
-
Jiri Denemark -
Michal Privoznik -
Michal Prívozník
-
Peter Kukla