On Thu, 2009-11-05 at 10:12 +0100, Alain RICHARD wrote: > I am currently testing this version of vm.sh that is handling xmlfile > and path differently : Right. > - if use_virth=0, use xm as before > - if path and xmlfile, ignore path and issue a warning (you should use > xmlfile) > - if xmlfile only, use it > - if path, search for a file name under path or name.xml under path > and set xmfile to this file 1. If you set 'xmlfile' and 'path', the RA should produce a warning. 2. If you set 'path', it does a search when using 'virsh' for the right file and sets 'xmlfile' to it (since xmlfile handling was already written). > in the case of virsh, creation is handled using 'virsh create xmlfile' > if xmlfile is not empty, or 'virsh create name' if there is no > xmlfile/path configured. The 'xmlfile' patch always has worked this way; the 'path' patch just searches the path attribute for config files. > The effect of this is that the config file must be : > > > - an xml file, with or without .xml extension, if xmlfile or path > attribute is set > - else, a classic xen config file under /etc/xen > In order to stay compatible with current rgmanager configuration, we > must ensure that use_virsh is set to 0 for vm that use classical xen > conf files and path directive, else the vm fails to lauch because > virsh create is not able to handle xen config file and virsh start, > that is able to handle xen conf files, is not able to get the file > from an other location than /etc/xen. Right, good point. We can run the conf file through xmllint, and if it fails, assume it's 'xen', and revert to 'xm' during the search process. Libvirt description files are all XML. Furthermore, if you set 'use_virsh' to '1' explicitly, the resource agent needs to return an error if the config file does not pass this XML test. I do not want the agent to parse individual files in order to allow a user to have say /mnt/tmp/foo.xml with "<name>bar</name>" for the virtual machine. > An other point is that if libvirtd is not running, the status returned > by this vm.sh for a vm is always "indeterminate", so I have to launch > it and to disable the default libvirt network because I really don't > need it. Ok. > The last problem so far is that clusvcadm -M always end-up with an > error although the migration is working correctly : What version of libvirt do you have? -- Lon -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster