|
I would counter with, "Why would you shutdown the hypervisor before the
VMs?" In the PowerVM world you have the hardware hypervisor, which is the
machine itself and the HMC says "are you sure you want to shutdown this?
there are LPARs running" finally you have the Virtual IO Server, which
brings services to the other LPARs.
Does your DB Server warn you about shutting down the APP server or closing
all connections before shutting it down? No, that is for whoever owns the
machine to decide.
Going back to ESXi, the storage won't complain if I tell it to shutdown
while the entire VMware environment is using it...
And that is why the whole automation ecosystem exists. You set your own
rules and use the provided tools to implement it, it is pretty easy after
all.
On Tue, 26 Mar 2024 at 11:11, Patrik Schindler <poc@xxxxxxxxxx> wrote:
Hello Rob,set
thanks for having a look!
Am 26.03.2024 um 14:26 schrieb Rob Berendt <robertowenberendt@xxxxxxxxx
:
I checked my systems.
I use no "Power Controlling Partitions". This is a property you can
via the HMC.apply a
There is an option on my vios lpars, under advanced properties,"Automatic Start with Managed System". However it will not let me turn it
on.
Same here. I wonder about what is the underlying reason.
Since I frequently apply firmware updates I would not likely use anysuch options. After all, do I really want to have the firmware reboot go
start vios, and vios start IBM i and then shut it all down again to
possible two stage update?of
Of course not. But then, IBM delivers everything: Hard-, firm-, and
software. Is it so hard to set a flag somewhere so that even a two stage
update won't involve a full IPL of all subsequent LPARs?
My experiences come from the VMware ESXi world where I'm not aware of
multi-stage upgrades but a very comfy environment with automation being
normal instead of the need about coming up with more or less crappy
workarounds for things I'd expect to be already provided by the vendor.
Aside from that, there it's usually apply update, reboot host, done.
Anyway… the responses from you, Jim and Roberto reinforce my prejudice
about IBM Midrange LPAR handling being still inferior to VMware in terms
admin friendliness. Automation can be a measure to lessen human error,when
applied cautiously and correctly. Why would anybody switch off/reboot ahappen
server before LPARs/VMs have properly been shut down prior?
Now, I have my Power systems in remote data centers. Each a few hoursaway. I can power cycle, update, etc all remotely and do so frequently.
I've done firmware, vios, IBM i, etc all remotely. The only time I go to
the DC is to move cables, install new hardware, etc. Doesn't really
too often.circuit
Same here, for the LPAR based system.
Basically the thought that having all the lpars correctly start/end inthe proper sequence in the unlikely event that these data centers with
multiple power inputs, multiple UPS, multiple generators, multiple
breakers is not worth the hassle when I can do it manually for theminimal
chance of that occurring. And thus maintain control for themachinery
firmware/vios/os upgrades.
Yes, the event is very unlikely. But with an increasing about of
to take care of I like to make the computer "think" for me. I'm humanand I
tend to forget things.list
:wq! PoC
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx--
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.