Bug 249708 - [RHEL5 U1] virt-install needs option to turn off auto-boot after install
[RHEL5 U1] virt-install needs option to turn off auto-boot after install
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: python-virtinst (Show other bugs)
5.0
All Linux
high Severity medium
: ---
: ---
Assigned To: Hugh Brock
Virtualization Bugs
: FutureFeature, Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-26 11:48 EDT by Jeff Burke
Modified: 2009-12-14 16:04 EST (History)
4 users (show)

See Also:
Fixed In Version: RHEA-2007-0636
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-07 13:09:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to add noreboot flag (1.47 KB, text/x-patch)
2007-08-03 09:51 EDT, Hugh Brock
no flags Details

  None (edit)
Description Jeff Burke 2007-07-26 11:48:53 EDT
Description of problem:
 When doing a pxe install using a ks.cfg if the desired behavior after the
install is to shutdown virt-manager will hang.

Version-Release number of selected component (if applicable):


How reproducible:
 Always

Steps to Reproduce:
1. Install a DOM0, Then install a guest using a kickstart file. use the below
kickstart as a template.
  
Actual results:
 virt-manager hangs

Expected results:
 The system "should" shutdown but we know that virt-manger will reboot anyways.

Additional info:
This is the kickstart file:

install
key 49af89414d147589
nfs --server=bigpapi.boston.redhat.com
--dir=/vol/engineering/redhat/nightly/RHEL5.1-Server-20070723.nightly/5/i386/os
lang en_US.UTF-8
langsupport --default=en_US.UTF-8 en_US.UTF-8
keyboard us
network --device eth0 --bootproto dhcp
rootpw rhts
firewall --disabled
authconfig --enableshadow --enablemd5
selinux --enforcing
timezone --utc America/New_York
bootloader --location=mbr --driveorder=sda --append="rhgb quiet"
cmdline
shutdown
# The following is the partition information you requested
# Note that any partitions you deleted are not expressed
# here so unless you clear all partitions first, this is
# not guaranteed to work
clearpart --all --initlabel
autopart

%packages --ignoremissing --resolvedeps
Comment 1 Daniel Berrange 2007-07-26 11:55:35 EDT
A little software version information please....  The xen, virt-manager,
python-virtinst, libvirt and kernel-xen versions
Comment 2 Jeff Burke 2007-07-26 13:33:19 EDT
Dan, 
   From what I can tell it happens in every version that I have tried. But most
recently it is what is in the latest tree.

gnome-applet-vm-0.1.2-1.el5
libvirt-0.2.3-4.el5
libvirt-python-0.2.3-4.el5
libvirt-devel-0.2.3-4.el5
xen-3.0.3-33.el5
python-virtinst-0.103.0-2.el5
virt-manager-0.4.0-2.el5

Jeff
Comment 3 Daniel Berrange 2007-07-26 13:46:27 EDT
What architecture is your host Dom0 machine ? Is it also i386, or are you doing
a mixed 32-on-64  instalation ?

Also, when virt-manager hangs can you capture 'netstat -t -a -n -p'  as root -
there's a potential issue with leaking filehandles to dbus I want to eliminate.
Comment 4 Daniel Berrange 2007-07-26 13:51:49 EDT
Can you clarify what you mean by 'virt-manager hangs'?  Does the virt-manager
application itself stop responding, or is it merely that the guest OS doesn't
poweroff. I can reproduce the latter, but not the former.
Comment 5 Jeff Burke 2007-07-30 10:23:50 EDT
Dan,

   Steps to Reproduce:
1. Install a DOM0, Then install a guest using a kickstart file. use the below
kickstart as a template.

Comment 6 Jeff Burke 2007-07-30 10:24:18 EDT
install
key 49af89414d147589
nfs --server=bigpapi.boston.redhat.com
--dir=/vol/engineering/redhat/nightly/RHEL5.1-Server-20070723.nightly/5/i386/os
lang en_US.UTF-8
langsupport --default=en_US.UTF-8 en_US.UTF-8
keyboard us
network --device eth0 --bootproto dhcp
rootpw rhts
firewall --disabled
authconfig --enableshadow --enablemd5
selinux --enforcing
timezone --utc America/New_York
bootloader --location=mbr --driveorder=sda --append="rhgb quiet"
cmdline
shutdown
# The following is the partition information you requested
# Note that any partitions you deleted are not expressed
# here so unless you clear all partitions first, this is
# not guaranteed to work
clearpart --all --initlabel
autopart

%packages --ignoremissing --resolvedeps

Comment 7 Daniel Berrange 2007-07-30 10:27:59 EDT
This is no different to what you've already posted in comment #1, which I've
already tried. All that happens is the guest OS completes shutdown, but doesn't
power off. Virt-manager itself is still operational.

So again as per comment #4, can you clarify what you mean by 'virt-manager
hangs'?  Does the virt-manager application itself stop responding, or is it
merely that the guest OS doesn't poweroff. I can reproduce the latter, but not
the former.
Comment 8 Jeff Burke 2007-07-30 10:43:19 EDT
Dan,
 That is correct it it merely that the guest OS doesn't
poweroff. So or can never get a result code from virt-install because it never
returns.

Jeff
Comment 9 Daniel Berrange 2007-07-30 13:26:48 EDT
OK, this is expected behaviour - you have not told anaconda that you want the
guest to power off. You requested 'shutdown' which merely causes termination all
running processes. If you want the guest to power off you need to use 'poweroff'
in the kickstart config file.
Comment 10 Jeff Burke 2007-07-30 16:46:19 EDT
Dan,
    poweroff doesn't work either. This is why. If you use the the following
options in a ks.cfg here is the behavior

restart - the system reboots expected behavior.
halt - the system reboots _Unexpected_ behavior.
poweroff - the system reboots _Unexpected_ behavior.
shutdown - system appers to hang virt-install never exits.

The _ONLY_ way I can get expected behavior out of virt-manager is to hack
virt-manager script to not reboot when I say halt/poweroff

--- ./virt-install.orig
+++ ./virt-install
@@ -610,8 +610,7 @@ def main():
                     print "to the console to complete the installation process."
                     sys.exit(0)
             print "Guest installation complete... restarting guest."
-            dom.create()
-            guest.connect_console(conscb)
+            sys.exit(0)
         else:
             print ("Domain installation does not appear to have been\n"
                    "successful.  If it was, you can restart your domain\n"

 
Comment 11 Daniel Berrange 2007-07-30 16:51:16 EDT
This behaviour is intentional. The initial boot is done using the install
kernel/initrd. Once install is complete, whether the guest requests a reboot, or
a poweroff, the HV is configured to destroy the guest. Finally virt-install then
explicitly starts the guest again, this time booting off pygrub. If install
completed, the end state is always that the guest is left running.
Comment 12 Jeff Burke 2007-07-30 17:30:57 EDT
It may be intentional but it is not desired. On every other system (other then
DomU) if I tell anaconda to poweroff it does and guess what it stays off. 

On every other system (other then DomU) if I tell anaconda to halt it does and
guess what it stays off.

Why did you tell me in Comment #7 to use poweroff if you knew it would not power
off?

If you are not going to fix the bug then can you at least add a command line
option to virt-install so it will not reboot automatically when you tell it not
to. For example: 

    parser.add_option("", "--noreboot", action="store_false",
                      default=True, dest="nrb",
                      help="Don't reboot after a successful install")
Then ifdef 
            dom.create()
            guest.connect_console(conscb)

Comment 13 Daniel Berrange 2007-07-30 17:38:51 EDT
I though you merely want to make the guest not sit idle in its 'shutdown, but
running state'. You simply want to prevent virt-install from automatically
starting the guest once install is complete. Virt-install has no way to detect
whether the installer within the guest did a poweroff vs reboot. All we see is
that the domain is destroyed & thus restart. So adding a flag to virt-install is
the only practical option. Changing subject to reflect what this ticket is
actually requesting, since there is no actual hang here.
Comment 14 Don Zickus 2007-07-30 17:50:53 EDT
This undesired behaviour is currently preventing Jeff and Martin from doing
_full_ automation tests on xen guests.  Currently Martin has a static setup
which prevents us from discovering bugs with other platforms.

If you could work with Jeff to fix this quickly, it will allow the xen tests to
move through QE much quicker.

Thanks.
Comment 15 Daniel Berrange 2007-07-30 18:04:33 EDT
The lack of this flag shouldn't block full automation. If you pass the
--noautoconsole flag to virt-install, it will skip popping up of the VNC viewer
windows and instead exit the moment the initial VM has been kicked off for
installation - ie it won't wait for completion of install, or restart it after
completion. Whatever test scripts are calling virt-install can thus simply wait
for the domain in question to get into shutdown (indicating completion of the
install process) and it'll be left in the shutoff state.
Comment 16 Jeff Burke 2007-07-30 22:04:08 EDT
Dan,
   You are right it does not block full automation, The reason is because I
patch virt-install so it will not reboot. But, I don't want to carry a patch
around for every update of RHEL5. 

   Please let me know when you have an updated python-virtinst package with an
updated virt-install with the --noreboot option availble to test. 
Comment 17 Daniel Berrange 2007-07-30 23:07:41 EDT
Requesting exception flag since we'll not be able to add features at this late
stage in RHEl-5.1 process without it approved.
Comment 18 Martin Jenner 2007-08-02 16:03:12 EDT
I support this exception fully - this would be big win for automated testing.
Comment 20 Hugh Brock 2007-08-03 09:51:50 EDT
Created attachment 160613 [details]
Patch to add noreboot flag

The attached has been added to cvs and the result built in brew.
Comment 21 Hugh Brock 2007-08-03 11:31:54 EDT
FYI, the patched build is python-virtinst-0.103.0-3.el5.
Comment 25 errata-xmlrpc 2007-11-07 13:09:37 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2007-0636.html

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