Bug 539496 - virt-manager doesn't save storage device changes in /etc/xen/guestname
Summary: virt-manager doesn't save storage device changes in /etc/xen/guestname
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: virt-manager
Version: 5.4
Hardware: x86_64
OS: Linux
urgent
high
Target Milestone: rc
: ---
Assignee: Cole Robinson
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 513358 (view as bug list)
Depends On:
Blocks: 548365
TreeView+ depends on / blocked
 
Reported: 2009-11-20 11:40 UTC by Troels Arvin
Modified: 2010-03-30 08:50 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-03-30 08:50:33 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Section of recent lines from /root/.virt-manager/virt-manager.log (4.72 KB, text/plain)
2009-11-20 13:43 UTC, Troels Arvin
no flags Details
Make sure hotplug changes are persistent (7.91 KB, text/plain)
2009-12-16 00:06 UTC, Cole Robinson
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2010:0281 0 normal SHIPPED_LIVE virt-manager bug fix update 2010-03-29 13:59:22 UTC

Description Troels Arvin 2009-11-20 11:40:02 UTC
Description of problem:
When I add or remove a virtual disk to a guest, the change isn't made permanent in /etc/xen/<guest name>. I have to subsequently manually add/remove the disk in the xen configuration file.

Version-Release number of selected component (if applicable):
libvirt-0.6.3-20.1.el5_4
virt-manager-0.6.1-8.el5

How reproducible:
All the time.

Steps to Reproduce:
1. Open virt-manager, providing root's password.
2. Open a guest, let's call it "fooguest".
3. Add a new PHY storage device device (one from /dev/mpath, in my case)
4. The storage device appears in the guest's /var/log/messages. So far so good.
5. But even after closing virt-manager, the configuration isn't made permanent in /etc/xen/fooguest; instead, I have to manually adjust the "disk = ..." line for fooguest.

  
Actual results:
/etc/xen/fooguest not changed; the ctime of the file is in the past.

Expected results:
After step 3, /etc/xen/fooguest should have been properly updated to reflect the added/removed storage device(s).

Additional info:
The guest is a paravirtualized RHEL 5.4 instance.

Comment 1 Chris Lalancette 2009-11-20 12:03:23 UTC
Yes, I do believe this is deliberate behavior, at least in the underlying libvirt API.  The libvirt attach/detach commands are not meant to be permanent; the way to permanently add a device to the guest is to modify the guest XML.

That being said, it might be nice if virt-manager had a check-box for "make this device permanent".  At that point, it would not only use the libvirt API to do the attach, it would also modify the guest XML.

Cole, what do you think about that?

Chris Lalancette

Comment 2 Troels Arvin 2009-11-20 13:18:24 UTC
Chris: But it _used_ to work: Changes made in virt-manager were saved to the configuation files.

(Although there were also bugs related to this in the earliest RHEL-release: virt-manager would make two references to the same storage device when a new device was added, or something like that.)

Comment 3 Chris Lalancette 2009-11-20 13:21:24 UTC
Ah, OK.  A different story then, a regression.  I'll mark it as such.

Chris Lalancette

Comment 5 Cole Robinson 2009-11-20 13:29:10 UTC
Troels, can you attach ~/.virt-manager/virt-manager.log?

Also, is the guest being shutdown at any point? If not, can you try adding the
disk, verifying it works, then stop the guest and see if the /etc/xen file has
been updated? Libvirt may have changed to not immediately write the config to
disk.

Comment 6 Troels Arvin 2009-11-20 13:43:16 UTC
Created attachment 372491 [details]
Section of recent lines from /root/.virt-manager/virt-manager.log

Comment 7 Troels Arvin 2009-11-20 13:44:35 UTC
The guest hasn't been shut down at any point. I may get a chance to shut it down soon, and then I'll return with additional info.

Comment 8 Cole Robinson 2009-11-20 14:21:52 UTC
I see the problem now. Strangely I've stared at this code 50 times and never realized that it is busted in the way you describe. I'm pushing a patch upstream shortly, should be a simple backport for 5.5.

You can work around this issue by doing something like 'virsh dumpxml <vmname> > foo.xml && virsh define foo.xml' which will make the change permenant.

Comment 9 Troels Arvin 2009-11-20 14:28:37 UTC
Can't you make a fix for 5.4? It's potentially a very serious operational problem if an administrator has made a change (believing that the change is permanent), but bad things happen next time the host or the guest is restarted.

About the workaround:
Does the command need to be run each time a change has been made in virt-manager, or is it a one-time fix? What does the command do, execept for creating a file "foo.xml" - Does it update /etc/xen/guestname? Does it update other files?

Comment 10 Cole Robinson 2009-11-20 14:40:05 UTC
(In reply to comment #9)
> Can't you make a fix for 5.4? It's potentially a very serious operational
> problem if an administrator has made a change (believing that the change is
> permanent), but bad things happen next time the host or the guest is restarted.
> 

I suppose you're right, I'll start moving on that.

> About the workaround:
> Does the command need to be run each time a change has been made in
> virt-manager, or is it a one-time fix? What does the command do, execept for
> creating a file "foo.xml" - Does it update /etc/xen/guestname? Does it update
> other files?  

The command would need to be run each time a device is hotplugged or hotunplugged from a VM in virt-manager. The command 'defines' the running VM config, basically saving it to disk. So in your case, the running VM config contains the hotplugged disk, but not the permenant config in /etc/xen. The command is saying

save the running VM config to foo.xml &&
read in foo.xml and save that config to disk

It should not update any other files, it is what virt-manager used to do for you but now does not.

Comment 11 Cole Robinson 2009-12-14 02:08:20 UTC
*** Bug 513358 has been marked as a duplicate of this bug. ***

Comment 13 Cole Robinson 2009-12-16 00:06:02 UTC
Created attachment 378659 [details]
Make sure hotplug changes are persistent

This change was a bit of a pain as the libvirt /etc/xen driver has no concept of 'inactive' XML, which current upstream code deals with incorrectly.

This patch adds a hack to lookup the current XML before the hotplug, and make the persistent change based on that (if we use the post hotplug XML, we end up with the double device issue we had in older versions).

I tested with Xen PV, Xen FV, and KVM guests, and all seem to give the desired behavior.

Comment 14 Cole Robinson 2009-12-16 00:16:29 UTC
Fix built in virt-manager-0_6_1-10_el5

Comment 20 errata-xmlrpc 2010-03-30 08:50:33 UTC
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.

http://rhn.redhat.com/errata/RHBA-2010-0281.html


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