Bug 472600 - virt-manager doesn't update the inactive guest config
virt-manager doesn't update the inactive guest config
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: virt-manager (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Cole Robinson
Virtualization Bugs
Depends On:
  Show dependency treegraph
Reported: 2008-11-21 17:30 EST by Odd Waller
Modified: 2010-10-23 02:09 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-02 05:42:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Odd Waller 2008-11-21 17:30:01 EST
Description of problem: When adding a block device to a xen virtual machine while in the anaconda installer, the domain config file gets updated with a kernel, ramdisk and extra parameter and the bootloader is removed. (when done through virt-manager)

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

How reproducible: Consistently

Steps to Reproduce:
1. click new in virt-manager (fill in all all info)
2. when the anaconda installer has started cat /etc/xen/system1

name = "system1"
uuid = "169c7751-a052-1e7d-33f7-becdad99b168"
maxmem = 512
memory = 512
vcpus = 1
bootloader = "/usr/bin/pygrub"
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
vfb = [ "type=vnc,vncunused=1" ]
disk = [ "phy:/dev/VolGroup00/VM4,xvda,w" ]
vif = [ "mac=00:16:3e:53:6e:a3,bridge=virbr0" ]

3. While anaconda is running. add a block device and update hardware specs.

4. cat /etc/xen/system1

name = "system1"
uuid = "169c7751-a052-1e7d-33f7-becdad99b168"
maxmem = 512
memory = 512
vcpus = 1
kernel = "/var/lib/xen/virtinst-vmlinuz.vz2hTr"
ramdisk = "/var/lib/xen/virtinst-initrd.img.ZCn4J_"
extra = "method="
on_poweroff = "destroy"
on_reboot = "destroy"
on_crash = "destroy"
vfb = [ "type=vnc,vncdisplay=0" ]
disk = [ "phy:/dev/VolGroup00/VM4,xvda,w", "phy:/dev/VolGroup00/VM5,xvdb,w" ]
vif = [ "mac=00:16:3e:53:6e:a3,bridge=virbr0,script=vif-bridge" ]

Virt-manager has now removed 

bootloader = "/usr/bin/pygrub" 

and added 

kernel = "/var/lib/xen/virtinst-vmlinuz.vz2hTr"
ramdisk = "/var/lib/xen/virtinst-initrd.img.ZCn4J_"
extra = "method="

Actual results:
This has now put you VM in an unbootable state.

Expected results:
The only parameter that should have been updated is disk. 

Additional info:
Comment 1 Odd Waller 2008-11-24 11:31:14 EST
Some additional information. From the redhat support team who has escalated it to developers/ engineering.

the same thing happens if a network card is attached instead of block device.

1- If block devices are attached to a guest during anaconda installation, it removes "bootloader" line and adds kernel, ramdisk and extra parameters which leaves the system not bootable after the installation is finished.

2- If block devices are attached to a running guest, it adds kernel, ramdisk and extra parameters to the guest config file which is undesirable, but wouldn't leave the system not bootable.

3 - If block devices are attached to a guest offline - after it was shutdown - everything works as expected.
Comment 3 Cole Robinson 2009-02-15 19:53:35 EST
This is a virt-manager issue, though I don't really know how to go about fixing it.

When you install a VM, there are two configs at play: the 'install' cfg which sets the boot device to the install media (among other things), and the 'post-install' cfg, which sets the boot device to the primary harddisk. What we do is boot the 'install' config, then immediately define the 'post-install' config: at the libvirt level, this means that after the VM shuts down, the post-install config takes effect. However, when you query the installing VM before it's first shutdown, libvirt will return the 'install' config (since that is what's currently running).

So when you add a device to the VM running with it's 'install' config, we splice in the new device xml, and redefine with the altered 'install' config, overwriting the 'post-install' config. This will leave the kernel values in your VM desc on VM restart, which won't work since we delete the install kernel after installation is complete.

So, solutions are either:

1) Deliberately disable adding devices to the VM xml if it is installing (well, hotplug should be okay).

2) Query VM's persistent config rather than running config ( There are flags for this in libvirt, though I have no idea how consistently they are implemented)
Comment 7 Cole Robinson 2009-02-26 11:39:19 EST
Okay, I'll make sure this gets fixed for 5.4.
Comment 8 Cole Robinson 2009-03-09 01:14:30 EDT
Okay, this is fixed upstream:


Device adding is still allowed, we just explictly update the 'inactive' guest config, which should fix this issue.
Comment 9 Cole Robinson 2009-03-23 15:38:04 EDT
Should be fixed in virt-manager-0.6.1-1.el5. Setting to MODIFIED.
Comment 11 Chris Ward 2009-07-03 14:14:00 EDT
~~ Attention - RHEL 5.4 Beta Released! ~~

RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner!

If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity.

Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value.

Questions can be posted to this bug or your customer or partner representative.
Comment 12 Mark Xie 2009-07-15 02:30:26 EDT
Here is my testing result of virt-manager-0.6.1-6.el5

1, start a xen host and create a new fv vm
2, copy /etc/xen/guest-config-file to save1/save2/save3/save4/save5 at time of
        1) once the guest creation successfully (save1)
        2) add a new storage which before package installation (save2)
        3) add some other hardware (save3)
        4) the guest before installation finish. (save4)
        5) after the installation finish. (save5)


Only the first added hardware can add successful, the same as the described #8

        1) # cat save1

name = "testins"
uuid = "96ada410-05f0-5af7-ce0b-722a281ca74d"
maxmem = 512
memory = 512
vcpus = 1
builder = "hvm"
kernel = "/usr/lib/xen/boot/hvmloader"
boot = "c"
pae = 1
acpi = 1
apic = 1
localtime = 0
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
device_model = "/usr/lib/xen/bin/qemu-dm"
sdl = 0
vnc = 1
vncunused = 1
keymap = "en-us"
disk = [ "file:/var/lib/xen/images/testins.img,hda,w", ",hdc:cdrom,r" ]
vif = [ "mac=00:16:36:24:41:b0,bridge=xenbr0,script=vif-bridge" ]
parallel = "none"
serial = "pty"

        2)#diff save1 save2

(None output)

        3) #diff save2 save3

< boot = "c"
> boot = "d"
< on_reboot = "restart"
< on_crash = "restart"
> on_reboot = "destroy"
> on_crash = "destroy"
< disk = [ "file:/var/lib/xen/images/testins.img,hda,w", ",hdc:cdrom,r" ]
< vif = [ "mac=00:16:36:24:41:b0,bridge=xenbr0,script=vif-bridge" ]
> disk = [ "file:/var/lib/xen/images/testins.img,hda,w", "file:/root/Desktop/test-add.img,hdb,w", "file:/root/Desktop/RHEL5.3-Server-20090106.0-i386-DVD.iso,hdc:cdrom,r" ]
> vif = [ "mac=00:16:36:24:41:b0,bridge=xenbr0,script=vif-bridge,vifname=vif7.0" ]
> soundhw = "es1370"

        4) #diff save3 save4

(None output)

        5) #diff save4  save5

(None output)

My testing environment:
Comment 13 Chris Ward 2009-07-15 04:12:26 EDT
Mark, i'm not aware of this issue but i would like to clarify; are you reporting that this issue is or is not resolved in the latest package builds?
Comment 14 Mark Xie 2009-07-15 04:54:09 EDT
(In reply to comment #13)
> Mark, i'm not aware of this issue but i would like to clarify; are you
> reporting that this issue is or is not resolved in the latest package builds?  

Chris, sorry for that, this bug have been fixed :)
Comment 17 errata-xmlrpc 2009-09-02 05:42:29 EDT
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 therefore 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.


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