Created attachment 1741710 [details] VirtMediaAutoAttach.png Description of problem: Trying to re-deploy on Dell setup using virtualmedia after the previous attempt of deployment using virtualmedia failed The deployment fails with error Error: could not inspect: could not inspect node, node is currently 'inspect failed', last error was 'Failed to inspect hardware. Reason: unable to start inspection: HTTP POST https://10.46.61.40/redfish/v1/Managers/iDRAC.Embedded.1/VirtualMedia/CD/Actions/VirtualMedia.InsertMedia returned code 500. Base.1.5.GeneralError: The Virtual Media image server is already connected. Extended information: [{'Message': 'The Virtual Media image server is already connected.', 'MessageArgs': [], 'MessageArgs': 0, 'MessageId': 'IDRAC.2.1.VRM0012', 'RelatedProperties': [], 'RelatedProperties': 0, 'Resolution': 'No response action is required.', 'Severity': 'Informational'}] Version-Release number of selected component (if applicable): 4.7.0-0.nightly-2020-12-21-131655 How reproducible: 100% Steps to Reproduce: 1. Ensure virtualmedia already attached 2. Run deployment using virtualmedia Actual results: deployment fails Expected results: ironic should disconnect the existing image before connecting a new Additional info: I've seen https://bugzilla.redhat.com/show_bug.cgi?id=1861025 for 4.6 and the provided solution, but on our setup Attach Mode already set to AutoAttach (see attached png)
Created attachment 1741711 [details] ironic conductor log
Hi, Lubov, What Dell hardware is it and what firmware version are you running?
(In reply to rlopez from comment #2) > Hi, Lubov, > > What Dell hardware is it and what firmware version are you running? Model PowerEdge R740 BIOS Version 2.8.1 iDRAC Firmware Version 4.22.00.00
Lubov, I went ahead and looked at my config and compared it to your virtual media configuration, difference between mine and yours is the Floppy Emulation is set to Enabled. I tested yesterday nightly: 4.7.0-0.nightly-2020-12-21-131655 and it installed successfully using virtual media. My config was: PowerEdge R640 BIOS: 2.8.1 iDRAC FW: 4.20.20.20 Options to try: 1) Latest iDRAC driver now is 4.40.00.00 available here: https://www.dell.com/support/home/en-us/drivers/driversdetails?driverid=62gw1&oscode=rhel8&productcode=poweredge-r740 -- maybe worth trying this latest iDrac FW see if you see the same result? 2) Downgrade to 4.20.20.20 and see if that works (since it works for me): https://www.dell.com/support/home/en-us/drivers/driversdetails?driverid=369m3&oscode=rhel8&productcode=poweredge-r740
To add, I'm quickly going to update my R640s to the latest 4.40.00.00 and report back.
So 4.40.00.00 indeed has issues. Seems like you indeed need specifically version 4.20.20.20 to proceed.
Went ahead and tested the following firmware versions and these all worked for me. 4.32.10.00 4.22.00.53 4.22.00.00
the problem here seems to be nothing to do with the redfish driver, only that vmedia is left attached after the redfish driver job fails the ironic code is doing an eject vmedia immediately followed by an insert this fails because it looks like the eject isn't synchronous waiting 2 seconds between the eject/insert is enough for it to succeed, a retry might also be an option, I don't see any callback url after the eject to check if its done [root@localhost html]# bash -x eject_insert.sh [3/1941] + curl -v -u XXX -k -H 'Content-Type: application/json' -H 'OData-Version: 4.0' https://10.46.61.41/redfish/v1/Managers/iDRAC.Embedded.1/VirtualMedia/CD/Actions/VirtualMedia.EjectMedia -d '{}' > POST /redfish/v1/Managers/iDRAC.Embedded.1/VirtualMedia/CD/Actions/VirtualMedia.EjectMedia HTTP/1.1 > Host: 10.46.61.41 > Content-Type: application/json > OData-Version: 4.0 > < HTTP/1.1 204 No Content < Date: Mon, 11 Jan 2021 20:55:05 GMT < Server: Apache < X-Frame-Options: DENY < Strict-Transport-Security: max-age=63072000; includeSubDomains; preload < * Connection #0 to host 10.46.61.41 left intact + curl -s -u XXX -k -H 'Content-Type: application/json' -H 'OData-Version: 4.0' https://10.46.61.41/redfish/v1/Managers/iDRAC.Embedded.1/VirtualMedia/CD/Actions/VirtualMedia.InsertMedia -d '{"Image": "ht tp://10.46.59.242:80/image.iso?filename=tmp4iq8w0u.iso", "Inserted": true, "WriteProtected": true}' {"error":{"@Message.ExtendedInfo":[{"Message":"The Virtual Media image server is already connected.","MessageArgs":[],"MessageArgs":0,"MessageId":"IDRAC.2.1.VRM0012","RelatedProperties":[],"RelatedPr operties":0,"Resolution":"No response action is required.","Severity":"Informational"}],"code":"Base.1.5.GeneralError","message":"A general error has occurred. See ExtendedInfo for more information"} } + sleep 2 + curl -s -u XXX -k -H 'Content-Type: application/json' -H 'OData-Version: 4.0' https://10.46.61.41/redfish/v1/Managers/iDRAC.Embedded.1/VirtualMedia/CD/Actions/VirtualMedia.InsertMedia -d '{"Image": "ht tp://10.46.59.242:80/image.iso?filename=tmp4iq8w0u.iso", "Inserted": true, "WriteProtected": true}' [root@localhost html]#
(In reply to Derek Higgins from comment #12) > the problem here seems to be nothing to do with the redfish driver, only > that vmedia is left attached after the redfish driver job fails > > the ironic code is doing an eject vmedia immediately followed by an insert > this fails because it looks like the eject isn't synchronous > waiting 2 seconds between the eject/insert is enough for it to succeed, a > retry might also be an option, I don't see any callback url after the eject > to check if its done Removing the blocker flag as removing any vmedia before starting the deployment will prevent this occurring.
Verified on 4.7.0-0.nightly-2021-01-31-031653 by running the scenario mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1910739#c10
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Container Platform 4.7.0 security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:5633