https://bugzilla.novell.com/show_bug.cgi?id=343603#c1 James Fehlig changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #1 from James Fehlig 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#c3 --- Comment #3 from James Fehlig 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 '. Is the config file name same as vm name? If so, what you are really doing is starting vm 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#c4 --- Comment #4 from Darren Thompson 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 '. Is the config file name same as vm name? If so, what you are really doing is starting vm 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 James Fehlig 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 ragoddard@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=343603#c7 --- Comment #7 from Randall Goddard 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.