Bug 412911

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

*** Bug 303201 has been marked as a duplicate of this bug. ***

*** Bug 303111 has been marked as a duplicate of this bug. ***

Created attachment 339000 [details]
virsh based vm.sh

This vm.sh is incomplete.  What is missing:

* Restore all xm commands because xm supports a "--path" during creation / deletion which is in use by customers.  KVM does not support this, so there's no reason to support it.

* (Optional) Provide a global override for defaults in resource agents (requires changes to rgmanager):
  <resource-defaults>
    <vm uri="qemu:///system" />
  </resource-defaults>

Would be nice because it's a pain in the butt to have to specify the same thing over and over and over (once per VM).  This is particularly nasty with migration mappings.  As an alternative, we can tell people to change their content defaults directly within vm.sh.

* The migration operation function also is incorrect and does not currently work.

Created attachment 343995 [details]
More complete implementation

virsh or xm-based vm.sh.

Unit tests done with only basic required values (virtual machine name and use_virsh set to 0 to force XM mode when required):

* virsh mode
  * with kvm/qemu
    * start = OK
    * stop = OK
    * status = OK
    * migrate = NO TESTING DONE
  * with Xen
    * start = OK
    * stop = OK
    * status = OK
    * migrate = OK
* xm mode (Xen only)
  * start = OK
  * stop = OK
  * status = OK
  * migrate = OK

Created attachment 343999 [details]
ocf-shellfuncs file (needed to hand-test vm.sh)

*** Bug 488024 has been marked as a duplicate of this bug. ***

Update:

Did unit tests in the above cases live migration enabled.

Everything seems to work, but a strange thing occurred - virsh reports a domain as "shut off" when migrating it to another host.  For example:

[root@lisa ~]# OCF_RESKEY_name=r5filebacked0 ./vm.sh migrate marge
Hypervisor: xen
Management tool: virsh
Hypervisor URI: xen:///
Migration URI format: xenmigr://target_host/
CMD: virsh migrate r5filebacked0 xen:/// xenmigr://marge/

(another terminal)
[root@lisa ~]# virsh list

 Id Name                 State
----------------------------------
  0 Domain-0             running
 15 r5filebacked0        shut off

When using live migration, it reported the state as expected (running or idle).

Still need to get a KVM cluster to test live-migration on KVM and locate common migration failure cases for the other bz.

The previous comments should not affect cluster operation since we do not currently check status on the migration-source, only the target, during the migration operation.  However, when we address bug 499835, it *may* become problematic.

Typically "shut off" means "shut off".

Created attachment 344875 [details]
Ready to go.

Few minor bugfixes.  I negative-tested qemu live-migration and did several other negative tests.  Also ensured that --path (the only reason we are keeping xm support) is still handled correctly.  Previous attachment didn't handle --path.

http://git.fedorahosted.org/git/?p=cluster.git;a=commit;h=94baaa8813089f1496b8a2564ec1874ea97c1f60

~~ Attention - RHEL 5.4 Beta Released! ~~

RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner!

If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity.

Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value.

Questions can be posted to this bug or your customer or partner representative.

Created attachment 357021 [details]
My working version for libvirt / kvm

The script from 'ready-to-go' didn't work at all with my Centos 5.3 server (latest updates).
I've made some changes.
And added a new xml paramter "config", where you can define directory
which holds libvirt xml files.
This way you can define and start a VM trough a simple XML file.
and manually defining it (on all cluster nodes) is not needed,
when you pick this file up from a NFS mount.

This can be used together with the snapshot parameter.
If no snapshot is there, the VM is defined based on the xml file.
If a snapshot is available, then the snapshot is restored.

This is not a production ready version, but at least starting and stopping kvm is working on centos 5.3

Hi Robert,

Please submit a patch to cluster-devel - I suspect yours conflicts somewhat with what was already merged upstream for specifying XML files (instead of directories).  Here is Federico Simoncelli's patch which was merged awhile ago:

http://git.fedorahosted.org/git/?p=cluster.git;a=commit;h=ea90559c936792e22576cac7a0bd0a2a50573426

The above patch is not in 5.4 beta.

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/RHSA-2009-1339.html