Description of Problem: This is a REGRESSION issue. When installing, the virtual machine doesn't startup once installation is completed and a reboot is requested. This problem doesn't occur on RHEL5.3 xen, libvirt, python-virtinst and virt-manager environment. Version-Release number of selected component: Red Hat Enterprise Linux Version Number: RHEL5.4 Release Number: beta Architecture: x86/x86_64/ia64 Kernel Version: kernel-xen-2.6.18-155.el5 Related Package Version: libvirt-0.6.3-11.el5, virt-manager-0.6.1-4.el5, python-virtinst-0.400.3-4.el5 Related Middleware / Application: Drivers or hardware or architecture dependency: None How reproducible: Always Step to Reproduce: 1. exceute virt-manager # virt-manager & 2. Begin install process from virt-manager's "Creating a new virtual machine" window. [Summary] machine name: vm2 Virtualization method: Paravirtualized Initial memory: 512MB Maximum memory: 512MB Virtual CPUs: 1 [Install media] Installation source: ftp://xxxx/rhel54/i386/ Kickstart source: [Storage] Disk image: /root/vm2.img Disk size: 5000MB [Network] Connection type: Shared physical device Target: xenbr0 MAC address: - 3. End install process, vm2 reboot. 4. vm2 disappeared from virt-manager window Actual Results: The new VM shuts down instead of rebooting. Expected Results: Vm reboots instead of shutting down when a reboot is requested during the install process.
I'm pretty sure this isn't a regression. This has always been the case with virt-manager, as far as I know. That is, at the end of installation, it just destroys the guest, and it's up to the user to start it manually. Note that the behavior for virt-install is different; virt-install *does* reboot guests at the end of installation. It's an unfortunate inconsistency in our tools, but since some people might be relying on the current behavior, we can't change it now. Can you please re-try with virt-manager from RHEL-5.3, and confirm that at the end of installation the behavior is the same as in RHEL-5.4? Chris Lalancette
No matter if this is a regression or not, it's not a xen issue, since virt-manager sets 'on_reboot = destroy' for the guest being installed. And xend does what it's asked for and destroys the guest when it reboots. Changing component to virt-manager.
On RHEL5.3, I confirmed that virt-manager keeps a guest on the list with 'Shutoff' state after the shutdown at the end of installation. However, on RHEL5.4, a guest disappears from the list on virt-manager after the installation and we can not reboot it with virt-manager. To show the guest on the virt-manager's list again, we have to re-connect to xen on the virt-manager. So I beleive this is a regression and it is too inconvenient for users to install guests with virt-manager.
There is already a libvirt bug tracking the 'disappear after force-off issue'. Closing as DUP, please reopen if this is actually a separate issue. *** This bug has been marked as a duplicate of bug 508278 ***
I'm not sure the root cause is same as bz508278, but this problem looks different so far because bz508278 reports that the problem occurs in RHEL5.3 as well. As far as my test, RHEL5.3 does NOT have this bz513958 problem at all.
(In reply to comment #9) > I'm not sure the root cause is same as bz508278, but this problem looks > different so far because bz508278 reports that the problem occurs in RHEL5.3 as > well. As far as my test, RHEL5.3 does NOT have this bz513958 problem at all. Well, some of the comments in 508278 seem to suggest that it only happens under certain circumstances. So maybe your test method is one of those circumstances. In any case, please test the patch that we now have for 508278. If that doesn't fix it for you, please re-open this BZ. Chris Lalancette
Fujtsu reported that the patch for bz508278 doesn't fix this problem. I also double-checked it with the patch and RHEL5.4 snapshot5, and the problem still occurs.
There was activity, and another patch added to 508278 that specifically fixed the issue when using virt-manager. So closing as a dup (again :) ). If the issue is still present in 5.4, please open a separate bug report since this bug has become difficult to navigate. Please provide a clear indication of how to reproduce, the behavior you are seeing, and expected (correct) behavior. *** This bug has been marked as a duplicate of bug 508278 ***