Description of problem: stage build 7/24 recreate: 1.Provision xen or kvm guests on a sat 2. delete the system profiles of the guests 3. virsh destroy the guests on the system 4. restart libvirtd and run rhn-profile-sync systems are still listed. This may be my fault as I opened a bug to remove the "delete" option on that page. Maybe we can restore that option and rename it something other than delete.
fixed in spacewalk master 8631578e03a62b7329dab7fa5ff2742f5156c717
The fix for the entitlement issue was as follows: The old code was removing the virt entry for the guest and then deleting the guest system via the delete_server stored procedure. The stored proc would see the system and see that it isn't a virt guest and decrement the entitlements. The fix is simply to call delete_server before removing the virt entry. This way the stored procedure knows it is still a virtual guest when it is deleting the entry.
satellite.git: ddcd4f39a0d5a51b72fbc06201cb610f51f5f5af
*** Bug 545976 has been marked as a duplicate of this bug. ***
Garik, how did you delete the systems through the UI? Did you do it through Systems-> VIRT HOST-> provisioning page? If you just went to the guest system and deleted them from there, the above behavior is expected. -Justin
To clarify (Justin can correct me if needed - I want this clear for any Q's from GSS or customer reading this bug) : Expected behavior because from Satellite point of view we do not know if the guest was stopped or completely deleted or if you just deleted its profile and plan to re-register it and if I am correct it will show guests as not registered. So, if you delete a registered guests systemid it will flip/show as an unregistered guest. You have to delete the guest entry from the VirtHost>provisioning page to remove it. I think this is what Justin was saying in a shorter description than myself. Cliff
Justin, Yea, right: removing through the guest system's details page - does not help them removing from host's virtual guests list. And I just confirm: removing them through: /rhn/systems/details/virtualization/VirtualGuestsList.do?sid=<sid> does the job correctly. Will continue verification with Satellite on RHEL 4. Please move the bug back to the on_qa. thanks.
Setting ON_QA as requested to speed up the process.
COMMENT - @Justin hi Justin, Thanks for highlighting the correct scenario here: Right, doing the following seems to be the corrected behavior of the system. 1. Register and make a client be xen host (with kernel-xen running as boot option) 2. through Satellite provision 2 virtual xen guests 3. Remove them through the "/rhn/systems/details/virtualization/VirtualGuestsList.do?sid=<xenhost_sid>" 4. Do "virsh destroy <guest_system_ids>" 5. Apply service libvirtd restart 6. update profile with: rhn-profile-sync 7. Go and look at the host's "Virtualization->Details" page [the guest systems should not be appeared there] This scenario is working OK. But I have a point here: doing the procedure above *does not* remove the images of guests from the host HDD, is it ok ? And due to this later on a try of provisioning a virtual guest with the same name FAILS !!! Please put a comment if it's ok or no. If ok - I will put the bug to verified then :) thx./
# COMMENT sorry - changed the "component" of the bug accidentally. returning it back to "WebUI" thanks tlestach for pointing it.
This is the way it has always behaved since Satellite 5.0 so I would say it is ok. I would agree we should probably add an RFE or a bug to actually schedule an action to do the 'virsh destroy' and rm -f /path/to/xen/image. (possibly making this optional). -Justin
# VERIFIED then: the issue is checked [described in comment#22] and working as expected now - the systems are not appearing back again after rhn-profile-sync once they were removed.
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/RHBA-2010-0369.html