[Bug 343603] New: XEN config files not kept in sync with virtmanager files, affects heartbeat cluster, autostart and XM command line tools
https://bugzilla.novell.com/show_bug.cgi?id=343603 Summary: XEN config files not kept in sync with virtmanager files, affects heartbeat cluster, autostart and XM command line tools Product: openSUSE 10.3 Version: Final Platform: Other OS/Version: SLES 10 Status: NEW Severity: Normal Priority: P5 - None Component: Xen AssignedTo: cgriffin@novell.com ReportedBy: darrent@akurit.com.au QAContact: qa@suse.de Found By: Third Party Developer/Partner Is it possible that you could circulate this around your team to see if anyone has a decent work-around/solution to this very annoying XEN/Virt-manager issue? In summary: I have noted that the VM configuration files created/updated by virt-manager are stored in /var/lib/xend/domains in uniquely identified folders (it's the UID of the VM) and in different format the the default XEN VM config file format. I also not that all of the command line XM tools, autostart , and heartbeat are all dependant on the text based config files stored in /etc/xen/vm. They are not kept in sync so any changes to the VM config using Virt-manager risks compromising the VM if used in heartbeat, autoload etc. It's a potential issue as the only way the "end customer" can configure new VM' is by virt-manager, yet I have to discourage them from ever using the tool again once the VM is created.... (seems very poor design to have such disconnected tools managing the same resource). Have you found a good way to keep these separate and disjointed configuration repositories in sync with each other???? I've become a bit of an expert at reading the Virt-manager files and hand crafting matching XEN config files, but it's a real pain to have to keep doing so.. Is there a new version of XEN/Virtmanager that does a better job of keeping these in sync or a tools available that can process one or the other of the config files to keep them in sync? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=343603 Charles Arnold <carnold@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |carnold@novell.com AssignedTo|cgriffin@novell.com |jfehlig@novell.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=343603#c1 James Fehlig <jfehlig@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #1 from James Fehlig <jfehlig@novell.com> 2007-11-26 10:31:57 MST --- (In reply to comment #0 from Darren Thompson)
I have noted that the VM configuration files created/updated by virt-manager are stored in /var/lib/xend/domains in uniquely identified folders (it's the UID of the VM) and in different format the the default XEN VM config file format.
The config files under /var/lib/xend/domains are managed by xend not virt-manager. Manipulating domUs via virt-manager will change the contents of the corresponding 'managed' config file by making calls to xend (through libvirt).
I also not that all of the command line XM tools, autostart , and heartbeat are all dependant on the text based config files stored in /etc/xen/vm.
heartbeat may be dependent on the 'legacy' config files. I will have to look into how heartbeat uses those files and possible alternatives. The xm tools do not use the 'legacy' files. You can of course do 'xm create' and supply _some_ config file stored anywhere accessible by dom0. But if you do an 'xm new' on that config you will get a 'managed vm', denoted by a new entry in /var/lib/xend/domains. Subsequent 'xm [block|network]-[attach|detach]', 'xm mem-set', etc. will changed the contents of /var/lib/xend/domains/<uuid>/config.sxp, regardless of whether domain is running or not. As for the xendomains script (which I assume is the 'autostart' feature you mention), you are right in that I don't think it is well integrated with 'managed vms'. However, the preferred method for autostarting domUs is to use on_xend_start="start" on_xend_stop="shutdown" in the domU config.
They are not kept in sync so any changes to the VM config using Virt-manager risks compromising the VM if used in heartbeat, autoload etc.
It's a potential issue as the only way the "end customer" can configure new VM' is by virt-manager, yet I have to discourage them from ever using the tool again once the VM is created.... (seems very poor design to have such disconnected tools managing the same resource).
Have you found a good way to keep these separate and disjointed configuration repositories in sync with each other???? I've become a bit of an expert at reading the Virt-manager files and hand crafting matching XEN config files, but it's a real pain to have to keep doing so..
I agree that this has been rather cumbersome since Xen moved to the notion of 'managed vms'. Most tools have been modified to only change domU config through the management APIs exposed by xend. The config files in /etc/xen/vm can be viewed as artifacts of the domU installation process. Once the installation is complete and the /etc/xen/vm/foo config has been "xm new'ed" into xend, then all subsequent manipulation of the vm should occur through virt-manager, xm, or even virsh. That said, perhaps not all of the relevant config a user might want to change is available for manipulation through one of the tools. In such cases, editing the config file is the only option. For these cases, exporting the exiting managed config (e.g. 'xm list --long > foo.sxp), editing the config, and then re-importing (e.g. xm new foo.sxp) is a workaround. Ultimately of course we would like to ensure the tools can handle manipulating all interesting and useful config options. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=343603#c2 --- Comment #2 from Darren Thompson <darrent@akurit.com.au> 2007-11-26 14:38:02 MST --- Created an attachment (id=184774) --> (https://bugzilla.novell.com/attachment.cgi?id=184774) More information The auto-start feature I was referring to was the use of the /etc/xen/auto directory. In summary you can copy (or symbolically link) on of the "legacy" config files from /etx/xen/vm into that directory and the VM will be automatically started the next time the host server is re-booted. This is an essential requirement for "stand alone" implementations where a single (Non clustered) server is hosting business critical VM' - In my case, small branch offices that need two host three VM' on the one physical server. I am not aware of any other technique for getting VM' auto started, please post specific details on how this can be done without the use of the "legacy" config files. As for the xm command lines, I have not specifically tested using the config files from the xend store but have found that "xm start config" loads the configuration of the "legacy" config file and that it is based on the physical name of the "legacy" config file. If there is a way of using the xend config store to achieve the same please post details. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=343603#c3 --- Comment #3 from James Fehlig <jfehlig@novell.com> 2007-11-26 15:55:28 MST --- (In reply to comment #2 from Darren Thompson)
I am not aware of any other technique for getting VM' auto started, please post specific details on how this can be done without the use of the "legacy" config files.
For managed domains, it appears the only option now is to export the config, edit, and re-import. http://www.novell.com/documentation/vmserver/virtualization_basics/index.htm... gives some details but essentially the steps I described in comment #1. On the edit step, change '(on_xend_start ignore)' to '(on_xend_start start)'.
As for the xm command lines, I have not specifically tested using the config files from the xend store but have found that "xm start config" loads the configuration of the "legacy" config file and that it is based on the physical name of the "legacy" config file.
'xm start config' is really just launching the vm based on the config in /var/lib/xend/domains/<uuid>/config.sxp. The syntax for start is 'xm start <dom_name>'. Is the config file name same as vm name? If so, what you are really doing is starting vm <dom_name> using the config in /var/lib/xend/domains/<uuid>/config.sxp. You should be able to nuke your config file in /etc/xen/vm and the 'xm start config' command you are using will continue to work. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=343603 James Fehlig <jfehlig@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact|qa@suse.de |jdouglas@novell.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=343603#c4 --- Comment #4 from Darren Thompson <darrent@akurit.com.au> 2007-11-27 12:14:51 MST --- Created an attachment (id=184941) --> (https://bugzilla.novell.com/attachment.cgi?id=184941) More info - Part II Quote:" On the edit step, change '(on_xend_start ignore)' to '(on_xend_start start)'" => I'll give that a try, thanks (Is it bad form to edit the config file in the XEND store directly?) Quote: "'xm start config' is really just launching the vm based on the config in /var/lib/xend/domains/<uuid>/config.sxp. The syntax for start is 'xm start <dom_name>'. Is the config file name same as vm name? If so, what you are really doing is starting vm <dom_name> using the config in /var/lib/xend/domains/<uuid>/config.sxp. You should be able to nuke your config file in /etc/xen/vm and the 'xm start config' command you are using will continue to work." => Oh... The config file is ALWAYS the same as the VM name so I had "assumed"... Thanks for that info - I now have a better understanding how this holds together. RE: Heartbeat, the available documentation does indicate a reliance on the "legacy" config files... http://www.novell.com/documentation/sles10/heartbeat/index.html?page=/docume... Similarly, the "normal" way to make XEN VM's available in a cluster environment was to create OCFS2 files mounts of /etc/xen/vm and /var/lib/xen/images which were then mounted via the HB2 cluster. If the /etc/xen/vm files are no longer to be used it does make clustering XEN VM' nerly impossible (There is no way that I know of to ensure both host servers are using exacly the same VM configurations). This is a well documented configuration: http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId=feature-18124html&sliceId=&dialogID=51787062&stateId=0%200%2051785718 http://wiki.novell.com/images/3/37/Exploring_HASF.pdf http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId=feature-19676html&sliceId=&dialogID=51787062&stateId=0%200%2051785718 This alone is a "show stopper" for the XEN and HB2 clustering. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=343603#c5 --- Comment #5 from James Fehlig <jfehlig@novell.com> 2007-11-28 11:04:56 MST --- (In reply to comment #4 from Darren Thompson)
=> I'll give that a try, thanks (Is it bad form to edit the config file in the XEND store directly?)
Yes. When xend starts it reads all the config under /var/lib/xend/domains and keeps it in memory. When config is changed (via various interfaces into xend), the memory is updated as well as changes flushed to corresponding config file. Fi changes are made to the config file directly, they won't be reflected in memory - unless xend is restarted.
RE: Heartbeat, the available documentation does indicate a reliance on the "legacy" config files... http://www.novell.com/documentation/sles10/heartbeat/index.html?page=/docume...
Similarly, the "normal" way to make XEN VM's available in a cluster environment was to create OCFS2 files mounts of /etc/xen/vm and /var/lib/xen/images which were then mounted via the HB2 cluster. If the /etc/xen/vm files are no longer to be used it does make clustering XEN VM' nerly impossible (There is no way that I know of to ensure both host servers are using exacly the same VM configurations).
This is a well documented configuration: http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId=feature-18124html&sliceId=&dialogID=51787062&stateId=0%200%2051785718 http://wiki.novell.com/images/3/37/Exploring_HASF.pdf http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId=feature-19676html&sliceId=&dialogID=51787062&stateId=0%200%2051785718
This alone is a "show stopper" for the XEN and HB2 clustering.
Right, which is why I have not closed this bug. Of all the items discussed in this report, the HB problem is certainly an issue. Investigation of possible solutions added to my todo list. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=343603 James Fehlig <jfehlig@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=343603 User carnold@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=343603#c6 Charles Arnold <carnold@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ragoddard@novell.com --- Comment #6 from Charles Arnold <carnold@novell.com> 2008-07-21 08:54:02 MDT --- *** Bug 410344 has been marked as a duplicate of this bug. *** https://bugzilla.novell.com/show_bug.cgi?id=410344 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=343603 User ragoddard@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=343603#c7 --- Comment #7 from Randall Goddard <ragoddard@novell.com> 2008-11-14 14:13:00 MST --- Our SysOp opened a thread on this issue in the linux-ha forum and another user appears to have posted a possible patch. http://lists.linux-ha.org/pipermail/linux-ha/2008-September/034610.html has the details. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com