+++ This bug was initially created as a clone of Bug #607379 +++ Description of problem: org.migrateSystems API call fails on Xen hosts Version-Release number of selected component (if applicable): v5.3.0 How reproducible: Any use of org.migrateSystems using a Xen host's system ID results in an internal systems error. Steps to Reproduce: #!/usr/bin/perl use Frontier::Client; $client = new Frontier::Client(url => "http://$HOST/rpc/api"); $session = $client->call('auth.login', $user, $pass); @list = ( 1000011023 ); $client->call('org.migrateSystems', $session, 122, \@list); $client->call('auth.logout', $session); Actual results: 500 Internal Server Error Expected results: No error. System 1000011023 should have been migrated from org 1 to org 122. Additional info: Extract from /var/log/tomcat5/catalina.out is attached. --- Additional comment from colin.coe on 2010-06-23 20:21:16 EDT --- Created attachment 426420 [details] catalina.out
The solution for the problem is not to try to untie virtual guests from their virtualization host during host migration as it's OK to have host and guests in different organizations. spacewalk.git master: 11008f331eee08c7999008d4e76345e7dfeefdc0
spacewalk.git: 52f03b3f2aa65780c51c1bf4f89397494b050be9
removing MigrationManagerTest.testRemoveVirtualGuestAssociations test (test doesn't make sence, since we support having host and virt guests in different orgs) spacewalk.git: 9c88fbded85fd1219a6131e2dab207fea6cd94ce
Moving ON_QA ...
This bug has been fixed in Spacewalk 1.3.