Bug 498446

Summary:	Moving VMs does not Update Satellite
Product:	Red Hat Satellite 5	Reporter:	David Glaser <dsglaser>
Component:	Virtualization	Assignee:	Devan Goodwin <dgoodwin>
Status:	CLOSED NOTABUG	QA Contact:	John Matthews <jmatthew>
Severity:	medium	Docs Contact:
Priority:	low
Version:	520	CC:	bperkins, jsherril
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-05-14 15:30:18 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description David Glaser 2009-04-30 14:53:24 UTC

Description of problem:

When moving a Virtual machine (not using xm) from one registered host to another registered host, the Satellite does not update that the VM has been moved. The VM shows up on the destination machine as an unregistered machine. 

This is even after running rhn-profile-sync on the source and destination hosts as well as the VM in question. 

Version-Release number of selected component (if applicable):

the VM was a RHEL 5.3 registered machine

How reproducible:

as often as I have tried

Steps to Reproduce:
1. Stop VM on source machine
2. Copy VM hard drive image to destination machine
3. use Virt-install to create domain for new machine, attach the VM hard drive image you copied.
4. Start the VM, configure networking if needed.
5. run profile sync on the destination machine, and the VM, which should tell the satellite that the VM is now on the destination machine 
  
Actual results:

The registered VM remains associated with the old machine, and the new VM shows up on the destination machine as an 'unregistered machine'.

Expected results:


Additional info:

Comment 1 Devan Goodwin 2009-05-04 19:54:16 UTC

Wow this could be a tricky one, there's a lot to think about here.

First up, can we even tell it's the same guest, after moving to a new host I think it will have a new UUID which definitely causes some problems for us, we're talking about rhn_check running on the host, which isn't aware of what's going on inside the guest in terms of what it's system ID or how/where it's registered. Without the UUID it's going to be extremely hard for us to even know it's the same guest.

I'm not even sure what the expected results would be. Were you thinking just simply that the guest profile would automatically be removed from the old host and associated with the new? Assuming we could find a way to detect that it's the same guest, can we safely assume the guest is never going to be started again on it's old host? (which could get weird, and the user may have intended to clone) Could we relocate the profile safely if the new host is in another org and has access to different channels etc?

Initial thoughts, honestly I think if this is done manually by the administrator there's little chance of us making the outcome sane without doing some crazy and probably very dangerous hacks and assumptions. If however we could offer host migration as a feature of our virt management UI in the future, then we would know it's happening and have some control over the guests, their system profiles and associations with hosts.

David if you could clarify if I've misinterpreted what you'd expect as a result please let me know! If it's simpler than the above in some way we might be able to come up with something.

Comment 2 Brandon Perkins 2009-05-05 15:46:14 UTC

As of right now, we do not support guest migration.  If you would like this functionality, please raise an RFE through support so that it can be considered for a future release.

For this particular problem, we feel the bug is exposed more by the process that was followed.  Instead of step 3. use Virt-install to create domain for new machine, attach the VM hard drive, simply the disk image and the Xen configuration, either /etc/xen/[GUEST] and/or /etc/sysconfig/rhn/virt/[UUID].xml should be copied over to maintain the UUID and MAC address for that guest.  Also, following the migration, 'python /usr/share/rhn/virtualization/poller.py' should be run as root on BOTH the old and new hosts.  This should then update the association.

We would be interested to know if this works for you.  If it does, then we would like to close this as NOTABUG (if we have not heard feedback in about a week).  But feel free to report an RFE through support if you would like additional functionality beyond what is stated above.

Comment 3 Brandon Perkins 2009-05-14 15:30:18 UTC

We did not receive any additional feedback on this issue.  Going to close it as NOTABUG.  Please either escalate the issue through Support or reopen this issue if you do not feel that it should be closed.