Open Stack

Devananda van der Veen <devananda.vdv at gmail.com> wrote on 05/13/2013
05:44:52 PM:


> Can you give an example of what hardware would not be supported?
>
> Any hardware which doesn't support mounting virtual media and
> exposing it to the guest -- this is, afaict, not part of the IPMI
> specification, though most large hw vendors have implemented it anyway.
>
> Also, this approach would be unsuitable for high-density compute
> where many SOCs share a single management board, even if that BMC
> supports virtual media, since this would serialize the deployment
process.
>
>  (caveat: I'm assuming that HDC systems whose BMC support virtual
> media would only support mounting a small number of, or just one,
> virtual media at a time. I base this assumption on the knowledge
> that some HDC systems have a limitation to the number of concurrent
> SOL sessions, which is considerably lower than the number of SOCs
> they contain.)
>

Correct, remote virtual media is not mandated nor standardized.

My thought on this was that one size fits all may be impractical.  I was
considering this as a deployment mechanism to avoid unauthenticated PXE
(actually I already implemented that in an IBM appliance).  Basically, PXE
being the default, and a pluggable remote-media solution to extend things
to support proprietary remote block device schemes.  This is one of the few
schemes I can conceive of to provide hard assurance of boot image integrity
in a failsafe fashion (meaning that doing it wrong is more likely to not
work at all than it is to function insecurely as I believe the case to be
for layer 2 filtering schemes).

Ideally, I would be for the feature to be standardized, even if not
mandatory.  For now though, that's not reality.

SOL is however highly standardized, and a trusted SSL socket requires
critically low amounts of data to bootstrap, so it might sound crazy but
workable for a serial-bootstrapped security model with well-understood SSL
providing the bulk of the activity.  At least in baremetal, it can come
relatively cheaply alongside a console manager (if a cooperative ipmi
implementation underpins it, the extra load would be lost in the noise of
the usual business of packet decryption, verification, and processing).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130513/2a46c6ce/attachment.html>