Bug 495834 - libvirt: the guest domain cannot be received shutdown signal during install
libvirt: the guest domain cannot be received shutdown signal during install
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Anaconda Maintenance Team
Release Test Team
Depends On:
  Show dependency treegraph
Reported: 2009-04-14 22:24 EDT by Nan Zhang
Modified: 2009-06-11 04:39 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-06-11 04:39:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
guest dmesg info (14.99 KB, text/plain)
2009-06-09 09:39 EDT, Nan Zhang
no flags Details

  None (edit)
Description Nan Zhang 2009-04-14 22:24:13 EDT
Description of problem:
As summary, invalid shutdown function.

Version-Release number of selected component (if applicable):
rhel5u3: 2.6.18-128.1.6.el5

How reproducible:

Steps to Reproduce:
1. define a guest domain from xml to install guest os
2. # virsh start kvmtest
3. # virsh shutdown kvmtest

Actual results:
Shutdown function is invalid during install.

Expected results:
The guest domain can be shutdown successfully.

Additional info:
It is normally shutdown after install finish. No this issue on Xen hypervisor.
Comment 1 Daniel Berrange 2009-06-08 08:44:01 EDT
Can you provide the XML config from 'virsh dumpxml kvmtest'   and the 'dmesg' output from inside the guest OS.  Also can you confirm whether 'acpid' process is running in the guest.
Comment 2 Nan Zhang 2009-06-09 03:00:08 EDT
The guest was installing status, so I could not get the 'dmesg' info from inside the guest OS, also cannot check the 'acpid' process in the guest.

[root@dhcp-66-70-85 ~]# virsh dumpxml kvmtest
<domain type='kvm' id='3'>
    <type arch='x86_64' machine='pc'>hvm</type>
    <cmdline>method=http://download.englab.nay.redhat.com/pub/rhel/rel-eng/RHEL5.4-Server-latest/tree-x86_64/ ks=</cmdline>
    <boot dev='hd'/>
  <clock offset='utc'/>
    <disk type='file' device='disk'>
      <source file='/var/lib/libvirt/images/kvmtest.img'/>
      <target dev='hda' bus='ide'/>
    <interface type='network'>
      <mac address='54:52:00:56:d0:17'/>
      <source network='default'/>
      <target dev='vnet0'/>
    <serial type='pty'>
      <source path='/dev/pts/3'/>
      <target port='0'/>
    <console type='pty' tty='/dev/pts/3'>
      <source path='/dev/pts/3'/>
      <target port='0'/>
    <input type='mouse' bus='ps2'/>
    <graphics type='vnc' port='5901' autoport='yes' keymap='en-us'/>
    <sound model='es1370'/>

[root@dhcp-66-70-85 ~]# virsh shutdown kvmtest
Domain kvmtest is being shutdown

[root@dhcp-66-70-85 ~]# virsh list --all
 Id Name                 State
  3 kvmtest              running
  - demo                 shut off
  - foo                  shut off
Comment 3 Daniel Berrange 2009-06-09 07:19:19 EDT
Once the graphical anaconda stage2 installer appears, you should be able to get a console shell by using Ctrl+Alt+F2 to switch to a alternate virtual terminal.

In any case, if the guest is ignoring ACPI shutdown signals during the installer, then there isn't really anything we can do from libvirt. For KVM we send an ACPI shutdown signal, and fact that this works post-install shows the libvirt bit is working.  So if we want this fixed, then it needs to be reassigned to ananconda IMHO.
Comment 4 Nan Zhang 2009-06-09 09:39:16 EDT
Created attachment 347025 [details]
guest dmesg info

Yes, I got the 'dmesg' info from the guest.
Comment 5 Daniel Berrange 2009-06-09 10:17:32 EDT
The dmesg logs show ACPI is enabled, so I can only assume the installer is not dealing with ACPI power button events. Changing component to anaconda
Comment 6 Chris Lumens 2009-06-09 10:26:18 EDT
anaconda doesn't do anything with ACPI at all.

Can we see a screenshot of the exact error messages?

Did this used to work and now has suddenly stopped working?  If so, between which versions?
Comment 7 Nan Zhang 2009-06-09 11:13:26 EDT
Doesn't work all the while, no extra error messages appears on screen during installer running. BTW, It can works well on Xen, just doesn't work on KVM.
Comment 8 Daniel Berrange 2009-06-09 11:34:10 EDT
In Xen, the controlled shutdown is triggered directly by the kernel in same way as C-A-D.  In KVM guests, the guest receives an ACPI power event, and thus needs acpid running to process this & request init to shutdown. My guess was that the stage2 anaconda process has not launched acpid, hence why i picked anaconda as the BZ component...
Comment 9 Joel Andres Granados 2009-06-10 07:26:52 EDT
Is there a way to avoid having to have acpid in the installer?

Does this also happen in f{10,11}? Maybe there is something that we can backport.
Comment 10 Joel Andres Granados 2009-06-10 07:40:32 EDT
Neil Zhang:
   Is this a matter of the installer not automatically rebooting after 
   installation?  Or is the issue only when you give the virsh shutdown command?
   Is `virsh destroy` not an option?
Comment 11 Daniel Berrange 2009-06-10 09:50:52 EDT
AFAIK, in RHEL-5 acpid is the only thing that deals with these kind of events in userspace.  

IMHO this bug is reasonably low importance. As you say, you can easily force a power off by using 'virsh destroy' instead of 'virsh shutdown'. Needing a graceful shutdown of the installer is not really critical since its stateless.

If RHEL-5 intsaller isn't already running acpid then perhaps its best to just WONTFIX this bug.
Comment 12 Chris Lumens 2009-06-10 09:57:25 EDT
We aren't running acpid at all in anaconda, and we never have in RHEL5 as far as I know.  I'll leave you guys to close this if you don't feel like it's worth investigating further.
Comment 13 Nan Zhang 2009-06-10 23:18:33 EDT
Joel and Daniel:
I agree to use 'virsh destroy' instead of 'virsh shutdown', I think this will not affect user experience. So if you think it's the low important issue, it could be closed.

Note You need to log in before you can comment on or make changes to this bug.