10:39 p.m.
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
.
3:19 p.m.
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
9:34 p.m.
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(a)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
12:20 a.m.
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
11:31 p.m.
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(a)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
4:28 a.m.
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
6:42 a.m.
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(a)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
2094
days inactive
2097
days old
6 comments
4 participants
participants (4)
-
Jiri Denemark -
Michal Privoznik -
Michal Prívozník
-
Peter Kukla