Bug 249708

A little software version information please....  The xen, virt-manager,
python-virtinst, libvirt and kernel-xen versions

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

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.

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.

Dan,

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

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

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.

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

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.

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"

 

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.

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)

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.

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.

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.

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. 

Requesting exception flag since we'll not be able to add features at this late
stage in RHEl-5.1 process without it approved.

I support this exception fully - this would be big win for automated testing.

Created attachment 160613 [details]
Patch to add noreboot flag

The attached has been added to cvs and the result built in brew.

FYI, the patched build is python-virtinst-0.103.0-3.el5.

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