Description of problem: /usr/share/cluster/vm.sh incorrectly assembles the command line arguments passed to xm (xen) to start a virtual machine Version-Release number of selected component (if applicable): 2.0.23-1 How reproducible: Always Steps to Reproduce: 1. clusvcadm -e vm:testvm1 Actual results: It fails with a "generic error" Apr 18 12:07:39 base1 clurgmgrd[4024]: <notice> start on vm "testvm1" returned 1 (generic error) Apr 18 12:07:39 base1 clurgmgrd[4024]: <warning> #68: Failed to start vm:testvm1; return value: 1 Apr 18 12:07:39 base1 clurgmgrd[4024]: <notice> Stopping service vm:testvm1 Expected results: Apr 18 12:07:40 base1 clurgmgrd[25585]: <notice> Service vm:testvm1 started Additional info: xm expects its arguments in the following way : xm <subcommand> [args] create [-c] configfile [name=value].. vm.sh tries to pass xm: xm create testvm1 restart="never" --path="/etc/xen/testvm1" what vm.sh _should_ have passed: xm create "/etc/xen/testvm1" restart="never" Faults: 1) vm.sh _pre-appends_ the virtual machine name to the arguments. xm does not understand this in that position 2) vm.sh _appends_ --path= to the arguments. xm does not understand --path= 3) vm.sh incorrectly puts the restart="never" argument _before_ the configfile argument. xm does not expect it in that position The attached patch fixed it for me.
Created attachment 153356 [details] Patch to fix vm.sh
The --path option (path in cluster.conf) should be a directory separated by colons. It does work, despite not being in the man page, and it is not directly analogous to the path="xxx" Xen config file option. Example: I created a bogus xen config file called "foo" and put it in /etc/xen and /tmp. Then, I called xm create foo --path="/mnt:/tmp". It selected the entry in /tmp and not /etc/xen (I did not place the entry in /mnt). [root@marge ~]# xm create foo --path="/mnt:/tmp" Using config file "/tmp/foo". Error: Invalid disk specifier: /dev/null,w [root@marge ~]# cat /tmp/foo # Automatically generated xen config file name = "foo" memory = "500" disk = [ '/dev/null,w', ] vif = [ 'mac=00:16:3e:32:0b:ff, bridge=xenbr0', ] vfb = ["type=vnc,vncunused=1"] uuid = "2287fbd8-75ab-5972-300f-37200e713c20" bootloader="/usr/bin/pygrub" vcpus=1 on_reboot = 'restart' on_crash = 'restart' [root@marge ~]# ls -l /tmp/foo -rw-r--r-- 1 root root 308 May 29 16:05 /tmp/foo [root@marge ~]# ls -l /etc/xen/foo -rw-r--r-- 1 root root 308 May 29 16:05 /etc/xen/foo [root@marge ~]#
That is - change your "path" attribute in cluster.conf to "/etc/xen" (or delete the path attribute entirely) and it will work.
Moving all RHCS ver 5 bugs to RHEL 5 so we can remove RHCS v5 which never existed.
So does this mean that the only place you can put your vm config file is /etc/xen?
Yes, but that's because of the following: https://bugzilla.redhat.com/show_bug.cgi?id=519786
There's a related patch in STABLE3 which adds 'xmlfile' for virsh support: http://git.fedorahosted.org/git/?p=cluster.git;a=commit;h=ea90559c936792e22576cac7a0bd0a2a50573426 This is more like what the bugzilla submitter wanted I think.
Thanks a lot Lon. I did not think I would get a reply for this post, as it was last updated in 2007. I spent a lot of time trying to figure out why the vm would not start when using Luci. Luci is a good tool but I think it needs a lot of work before it can be called enterprise. Specially in reporting back errors. In any case good work! Regards Sebastian