back to article Power Systems running IBM's VIOS virtualisation need a patch and reboot

IBM on Saturday slipped out news of a nasty bug in its VIOS, its Virtual I/O Server that offers virtualisation services on Power Systems under AIX. Issue IV91339 strikes when moving virtual machines and means “there is a very small timing window where the VIOS may report to the client LPAR that some I/Os have completed before …

  1. seven of five

    "So IBM's guidance guidance that will not go down well with users."

    Uh... why not?

    patch and boot the secondary, patch and boot the primary. Extra points if you are nice enough to disable the vscsi and vfcs of the corresponding vios first (rmdev -pl $adaptername). Ethernet fails over automatically, though you could add extra grace there as well.

    Hardly a big deal. And in order to run into iv91339s bug, you´d have to have a failing lpm in first place.

    1. Sooty

      Re: "So IBM's guidance guidance that will not go down well with users."

      yup, patching and rebooting a machine that supports multiple services, even with multiple load balanced clones might be technically easy...

      but the real world of big business usually requires you to fill out endless paperwork to try and explain what it is to non-techies, and to be able to prove beyond a doubt that the reboot itself, nor any patch activity, can possibly interfere with operations in any way.

      generally you even have to get approval from god just to lower resiliency by taking a clone out for a short period. But that does all depend on your service levels and data criticality.

      I'm sure the thought of creating change records and submitting them to a CAB don't fill all techies with dread, possibly.

      1. Michael Felt

        Re: "So IBM's guidance guidance that will not go down well with users."

        If this goes back as far as 2.2.3.X - then, clearly - it is not happening often - and management might decide that the higher risk to business is updating and rebooting a dual VIOS configuration.

        As far as change records go: whether they are a major pain or a minor pain or no pain - experience has taught many that no records - ultimately is a 'killing pain'. This again, is a process that can ensure that the business can manage their risk - as they view it. System administration is not the business - even that "we" have the best of intents "they" must okay the process. That is how business is done.

        The argument that should be made is that the systems were engineered for concurrent maintenance. Not doing the maintenance now may lead to a disruptive 'moment'. The business does not need to know the technical details - it needs to know the relative risk and impact on business. The design - aka best practice - of using dual VIOS is that the impact should be zero - even with a reboot!

  2. Anonymous Coward
    Anonymous Coward

    Why Dual VIOS is great to have

    Although there are reasons to go with a single VIOS and with more recent features that provide a cluster-like availability on other servers my preference within my organization is to deploy Dual VIOS. It's a nominal expense to deploy while having the ability to tell the business the platform will continue to service the dozens of VM's on each box while we do concurrent maintenance for each VIOS.

    We are not shy to our stakeholders either on how we've built our Power environment (starting with P4 and now mostly P8) so they have confidence in the platform and our ability to keep it all running virtually non-stop.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like