Description of problem: If a user attempts to provision a Xen PV guest with a guest name like this, via the WebUI: ------my---rhel5---server------ koan will interpret it as an argument, as demonstrated by the attached traceback. Version-Release number of selected component (if applicable): 530, 5/7 ISO How reproducible: Always Steps to Reproduce: 1. Provision a Xen PV guest via the WebUI and give it a name that begins with dashes 2. Run rhn_check -vvvvv on the client Actual results: Similar to attached rhn_check traceback Expected results: Either dashes placed at the beginning of a guest's name are not allowed or the client code is made more clever to deal with such eventualities Additional info:
So this seems to work fine for me. (I provisioned 2 different PV guests with dashes at the start of the name). Looking at the error: raise RuntimeError, _("The MAC address you entered conflicts with the physical NIC.")\n'}) I'm guessing that it had something to do with the system record that was created, but i'm not sure. Can you try to reproduce?
Despite multiple attempts at recreating this bug, I cannot, and, as thus, I can't reproduce the issue as reported. I'm going to CLOSE this as NOTABUG and reopen it if I come across this issue again.
So to reproduce: 1. register a virt host 2. create a system record for that virt host (system details -> provisioning -> create cobbler system record) 3. try to provision a guest to that machine e942b817d741fb8bd0301eff0dfbd74ccbeeb0a7
VERIFIED on 5/29 build.
fails stage testing D: handle_action actionid = 31603, version = 2 D: do_call kickstart_guest.initiate ('test1182.test.redhat.com', 'rlx-3-18.rhndev.redhat.com:62:systemrecordTest02', 'xenpv', 2422, 'systemrecordTest02', 512, 1, 3, 'xenbr2', '/var/lib/xen/images/systemrecordTest02', 'ksdevice=eth0 ') D: Attempt to call an unsupported action kickstart_guest.initiate ('test1182.test.redhat.com', 'rlx-3-18.rhndev.redhat.com:62:systemrecordTest02', 'xenpv', 2422, 'systemrecordTest02', 512, 1, 3, 'xenbr2', '/var/lib/xen/images/systemrecordTest02', 'ksdevice=eth0 ') D: Sending back response (6, 'Invalid function call attempted', {}) D: do_call packages.checkNeedUpdate ('rhnsd=1',) D: Called refresh_rpmlist Updating package profile D: local action status: (0, 'rpmlist refreshed', {}) D: closed db index /var/lib/rpm/Providename D: closed db index /var/lib/rpm/Packages D: closed db environment /var/lib/rpm/Packages D: May free Score board((nil)) [root@rlx-3-18 rpm-gpg]# /var/log/up2date e><string>xenbr2</string></value>\n</param>\n<param>\n<value><string>/var/lib/xen/images/systemrecordTest02</string></value>\n</param>\n<param>\n<value><string>ksdevice=eth0 </string></value>\n</param>\n</params>\n</methodCall>\n", 'version': 2, 'id': 31603} [Mon Aug 3 14:37:20 2009] up2date D: handle_action actionid = 31603, version = 2 [Mon Aug 3 14:37:20 2009] up2date D: do_call kickstart_guest.initiate ('test1182.test.redhat.com', 'rlx-3-18.rhndev.redhat.com:62:systemrecordTest02', 'xenpv', 2422, 'systemrecordTest02', 512, 1, 3, 'xenbr2', '/var/lib/xen/images/systemrecordTest02', 'ksdevice=eth0 ') [Mon Aug 3 14:37:20 2009] up2date D: Attempt to call an unsupported action kickstart_guest.initiate ('test1182.test.redhat.com', 'rlx-3-18.rhndev.redhat.com:62:systemrecordTest02', 'xenpv', 2422, 'systemrecordTest02', 512, 1, 3, 'xenbr2', '/var/lib/xen/images/systemrecordTest02', 'ksdevice=eth0 ') [Mon Aug 3 14:37:20 2009] up2date D: Sending back response (6, 'Invalid function call attempted', {}) [Mon Aug 3 14:37:20 2009] up2date D: do_call packages.checkNeedUpdate ('rhnsd=1',) [Mon Aug 3 14:37:20 2009] up2date D: Called refresh_rpmlist [Mon Aug 3 14:37:20 2009] up2date Updating package profile [Mon Aug 3 14:37:21 2009] up2date D: local action status: (0, 'rpmlist refreshed', {})
same repro as comment #5
sorry.. this actually works just fine.. rhn-host-virt was not installed due to reactivation key the virt guest came up fine.
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