Description of problem: While testing virt provisioning of a guest using koan, found that koan does not like profile names that contain a - character; however, this is valid for profiles in the UI. This bug may result in a change to koan, Satellite, both or neither; however, raising the issue as it would be good to have consistency; otherwise, users may create profiles that can be used in one place but not the other. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. create a kickstart profile where the name includes a - (e.g. rhel-guest) 2. use koan on the host to create guest (e.g. koan --server=<server> --virt --nogfx --profile=rhel-guest:1:Test-Cert) Actual results: koan --server=<server> --virt --nogfx --profile=rhel-guest:1:Test-Cert - looking for Cobbler at http://<server>/cobbler_api - reading URL: http://<server>/cblr/svc/op/ks/profile/rhel-guest:1:Test-Cert install_tree: http://<server>:80/ks/dist/ks-rhel-i386-server-5 downloading initrd initrd.img to /var/lib/xen/initrd.img url=http://<server>/cobbler/images/ks-rhel-i386-server-5:xen/initrd.img - reading URL: http://<server>/cobbler/images/ks-rhel-i386-server-5:xen/initrd.img downloading kernel vmlinuz to /var/lib/xen/vmlinuz url=http://<server>/cobbler/images/ks-rhel-i386-server-5:xen/vmlinuz - reading URL: http://<server>/cobbler/images/ks-rhel-i386-server-5:xen/vmlinuz invalid location: /var/lib/xen/rhel-guest Expected results: no 'invalid location' error and the guest is provisioned Additional info:
This has nothing todo with the hyphen, it is actually complaining that your virtual disk file is already on the file system: invalid location: /var/lib/xen/rhel-guest indicates that either the path is not accessible or the file *already* exists. This often happens if you kickstart more than one guest from the same profile because the profile now specifies the path. Perhaps we should be a bit smarter because by adding the path in the profile as we have now you can only kickstart one virtual guest from the GUI with the default, all subsequent kickstarts have to be overidden or you get the above error.
The following changes have been agreed upon 1) Remove Virt Path setting in Profiles.. 2) When a virt guest install is scheduled (under /rhn/systems/details/virtualization/ProvisionVirtualizationWizard.do) if a virt path is provided... use that and put it in the system record, else have the default be Config.get().getVirthPath() + "/" + $guestName and put that in the system record 3) in spacewalk koan , have it check to see if the directory has already been created... If so report a nice error message instead of just saying invalid location, invalid location /var/lib/xen/rhel-guest already exists, please change the virt storage path when provisioning the guest and reschedule..
should be resolved as of http://git.fedorahosted.org/git/?p=spacewalk.git;a=commit;h=20c2216d19621442a2e07418b8205b6468ba795f Changes pertaining to this commit.. 1) Virt Path, which used to be by default /var/lib/xen/{Profile Name} will now be /var/lib/xen/{GuestName} so that guests using the same profile name don't end up with duplicate paths.. 2) Improved the message on spacewalk-koan side to say the disk path already exists instead of "invalid location: /var/lib/xen/rhel-guest".. 3) Removed Virt Path references in the main kickstart details pages since virt path is only set in Virt Provisioning page..
Moving to ON_QA
VERIFIED on 5/29 build.
Ok the initial bug is a little confusing in Comment #1 It should be modified to 1. create a kickstart profile where the name includes a - (e.g. rhel-guest) 2. Use SDC -> Virturalization -> Provisioning -> Advanced Configuration and setup a Virt Disk Path to an already existing path on the host 3, Schedule the kickstart on the virt host. when you run rhn_check spacewalk koan package should complain that this path already exists and you should get a failed kickstart due to the duplicate path. 4.) Repeat Step 2 but now give a valid disk path (eg /var/lib/xen/{GuestName}) and kickstart again.. The Ks shoudl be successful.
i am seeing a failed action with the following reason: Client execution returned "Fatal error in Python code occured [[6]]" (code -1)
Verified in stage -> RELEASE_PENDING
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/RHEA-2009-1434.html