The AT generator test didn't happen last Friday. Instead it's looking likely to be Thursday 3rd March or Friday 4th.
E&B are trying to schedule a generator test for that part of the central area which includes Wilkie Building. They're aiming for some time between 23rd of May and 23rd of June (after exams and before graduations). We would expect power to be off in the Wilkie Building for a couple of hours, and we'll be surprised if it turns out that any of it is actually covered by the generator in question.
Ian will be looking at nut for SL7, for which a fairly large overhaul may be required, and will also think about the SMSR ideas we discussed last time.
Now that we have global IPv6 routing, it's open season for folk to try it out. (Interim) instructions are here. They seem to work for SL7 as well as SL6 (where most testing has been done to date). If anyone would like additional subnets added, please say so, though there are reasonable reasons why the initial set was restricted in the way it was. Alternatively, if you need to move your machine to a different subnet to try things out, instructions for that are here.
However, Sam writes: "I don't think we can say it's fully supported yet. I'm thinking of it as being somewhere between experimental and pilot. I'm not expecting you to have to renumber, but we don't yet know for sure. (But hey, IPv6 renumbering is simple, right?) Web pages are a bit of a thorny issue. We're in the process of creating a formal project to cover IPv6 rollout and documentation, even early development docs, will have to be an output from that. [...]"
The issues page is being updated as things progress, and the final report is being written as stages are completed.
At the Ops Meeting of 12th August 2015, we decided that we wanted to understand what our current provision of DRACs, iDRACS, BMCs, etc. was, and that we also wanted to standardize on a future specification for these kinds of devices.
Dell terminology doesn't particularly help here, but it seems that, for the '8th generation' of these devices (which are what's found in the current - i.e. 13th - generation of servers; i.e. those with a '3' as the penultimate digit of their model number, e.g. R730, etc.), the only possibilities - in ascending order of both price and sophistication, are the 'iDRAC8 Basic', the 'iDRAC8 Express', and the 'iDRAC8 Enterprise.' For a comparison of the capabilities of each of these, see the Dell: iDRAC 7 and 8 Feature and Licensing Comparison, Nov 2014 document.
From an 'infrastructural' point of view, 'all' that we want from such devices is standard support for IPMI v2.0: for our purposes - power control, a remote SOL console, and sensor readings/events. Some - but not all - of our current collection of such devices also offer 'out-of-band' ('out-of-IPMI-band, that is) access via HTTP and ssh; that has proven to be useful in remotely resetting the devices on a couple of occasions when IPMI functionality has 'gone wrong' in some way, but we don't consider it an essential feature.
As the above chart shows, there is a welter of additional functionality (and associated configuration ...) which we could buy into: e.g. SNMP traps; email alerts; etc. However, our suggestion is to keep it simple and to standardise, at the current generation, on the simplest and cheapest offering.
For servers in the 200-500 series, that implies the 'iDRAC8 Basic.' For more expensive servers - the 600 series and upwards - that implies the 'iDRAC8 Express', which is supplied as standard on those models.
Note that even the simplest of the three options, namely the 'iDRAC8 Basic' does, in fact, also offer 'out-of-band' access - so we will now have that as standard on any new servers we buy.
All three iDRAC8 options also offer something called 'Remote agent-free update' (see page 4 of the above document.) We are not sure what exact functionality that provides, but if, for example, it makes remote firmware/BIOS updates possible, it might prove very useful. We suggest that, as soon as we have machines thus equipped which we can use for testing, we investigate what this facility does offer.
Finally, in relation to existing hardware: bearing in mind that testing of the capabilities of the current DRAC/iDRAC/etc. offerings would require downtime and might lead to problems, we do not have machines readily available for aggressive testing. Therefore, we do not plan to do any such testing; nor do we plan explicitly to document which current server has which particular capability.
Please contact us with any comments or corrections.
Unless explicitly stated otherwise, all material is copyright The University of Edinburgh