[Bug 1202138] New: PowerPC machine crashes frequently after upgrading to Leap 15.4
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 Bug ID: 1202138 Summary: PowerPC machine crashes frequently after upgrading to Leap 15.4 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: PowerPC-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs@opensuse.org Reporter: marius.kittler@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- After upgrading a PowerPC machine (the openQA worker qa-power8-4-kvm.qa.suse.de) from Leap 15.3 to Leap 15.4 that machine crashes frequently. It usually does not stay on for more than a few hours. Downgrading the machine (by rolling back to the last BTRFS snapshot with Leap 15.3) allows the machine to run stable again. Note that there's actually a second machine (the openQA worker qa-power8-5-kvm.qa.suse.de) that we managed to operate without crashes on Leap 15.4. Both machines seems very similar to me so I'm not sure whether one is crashing and the other one not. Note that in the first place both machines did not boot on Leap 15.4. It seemed to be stuck at some point and the kernel logged messages like ``` [ 197.877239][ C62] watchdog: BUG: soft lockup - CPU#62 stuck for 25s! [swapper/62:0]` quite frequently ``` quite frequently. So I added the kernel parameter `nmi_watchdog=0`. With this parameter both machines could boot on Leap 15.4 (but as mentioned only qa-power8-5 runs stable without crashing). So the kernel command line used is: ``` root=UUID=89ca2dff-86af-478b-8d4c-2a45ca689fd5 nospec kvm.nested=1 kvm_intel.nested=1 kvm_amd.nested=1 kvm-arm.nested=1 crashkernel=210M nmi_watchdog=0 ``` Not sure what other details could be relevant. Unfortunately the journal does not have any interesting message right before the crash. Via SOL I could once see a kernel panic being logged: ``` QA-Power8-4-kvm login: [ 365.807470][ T3923] EXT4-fs error (device sdb1) in ext4_free_inode:362: Corrupt filesystem [ 438.050890][ T94] Kernel panic - not syncing: corrupted stack end detected inside scheduler [ 438.051046][ T94] CPU: 16 PID: 94 Comm: ksof ``` (The filesystem error is likely just a symptom of the crashes.) Any advice what I could try? Maybe another kernel parameter? Maybe booting Leap 15.4 but with the kernel version from 15.3 (not sure how I'd do that, though - so any advice would be welcome if that idea sounds helpful)? By the way, that's `/proc/cpuinfo` on the problematic machine: ``` root=UUID=eebe647f-e867-416e-a0fa-7a6732bfcf9d nospec kvm.nested=1 kvm_intel.nested=1 kvm_amd.nested=1 kvm-arm.nested=1 crashkernel=210M martchus@QA-Power8-4-kvm:~> cat /proc/cpuinfo processor : 0 cpu : POWER8, altivec supported clock : 3857.000000MHz revision : 2.0 (pvr 004d 0200) [��� repeated 7 more times with processor 8, 16, 24, 32, 40, 48 and 56] timebase : 512000000 platform : PowerNV model : 8348-21C machine : PowerNV 8348-21C firmware : OPAL MMU : Hash ``` On the stable machine it looks very similar but it is actually a model with more processors: ``` processor : 0 cpu : POWER8 (raw), altivec supported clock : 3857.000000MHz revision : 2.0 (pvr 004d 0200) [��� repeated 13 more times with processor 8, 16, 24, ���] timebase : 512000000 platform : PowerNV model : 8335-GCA machine : PowerNV 8335-GCA firmware : OPAL MMU : Hash ``` That's the relevant ticket on the openQA infrastructure tracker (for additional context): https://progress.opensuse.org/issues/114565 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 Takashi Iwai <tiwai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |msuchanek@suse.com, | |tiwai@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 Oliver Kurz <okurz@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |okurz@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c1 Michal Suchanek <msuchanek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marius.kittler@suse.com Flags| |needinfo?(marius.kittler@su | |se.com) --- Comment #1 from Michal Suchanek <msuchanek@suse.com> --- What is the firmware version of the machines? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c2 --- Comment #2 from Marius Kittler <marius.kittler@suse.com> --- Firmware of qa-power8-4-kvm.qa.suse.de as shown by the MBC: Device Information Firmware Revision: 2.16.65371 Firmware Build Time: Jun 13 2019 11:15:14 CDT BIOS Version: 1.12.96 --- Firmware of qa-power8-5-kvm.qa.suse.de as shown by the MBC (no BIOS Version shown here at all): Device Information Firmware Revision: 2.13.91819 Firmware Build Time: Mar 10 2016 10:59:31 CDT --- So the problematic worker runs on newer firmware. Do you think that could make the difference? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c3 --- Comment #3 from Michal Suchanek <msuchanek@suse.com> --- Not sure what that firmware revision relates to. Typically the POWER firmware revisions shown look something like SV840_FW840.00 (56) FW840.00 (SV840_056) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c4 --- Comment #4 from Marius Kittler <marius.kittler@suse.com> --- I've just read this under "Device information" in the BMC as dmidecode seems not available. So where would I find this version number? (I'm not a PowerPC expert.) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c5 --- Comment #5 from Michal Suchanek <msuchanek@suse.com> --- The ASMI (web management interface for the machine), and some random tools output it as well (it's seen multiple times in supportconfig). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c6 --- Comment #6 from Marius Kittler <marius.kittler@suse.com> --- With ASMI, do you mean the page accessible in this case via http://qa-power8-4.qa.suse.de/index.html (from SUSE VPN)? I've ran `supportconfig` on both machines but couldn't spot the firmware version there. I'll add the full logs in a private comment. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c9 --- Comment #9 from Michal Suchanek <msuchanek@suse.com> --- It look like the these machine are Opal-only so the the firmware version is not comparable with the PowerVM firmware versions The latest firmware available from https://www.ibm.com/support/fixcentral 8335-GCA: 8335_820.1923.20190604n_update.hpm OP8_v1.12_2.98.pd.sdd S822LC-8335-GCA-GTA-OpenPowerReadme_op820.30.xhtml 8348-21C: 8348_820.1923.20190613n.html 8348_820.1923.20190613n_update.hpm OP8_v1.12_2.96_H.dd.xml OP8_v1.12_2.96_H.pd.sdd The machines use different firmware build so the results between them are not really comparable. Please update the firmware on the problematic machine. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c10 --- Comment #10 from Michal Suchanek <msuchanek@suse.com> --- Actually, it looks like you have the latest firmware: 8348_820.1923.20190613n Firmware Revision: 2.16.65371 Firmware Build Time: Jun 13 2019 11:15:14 CDT BIOS Version: 1.12.96 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c11 --- Comment #11 from Michal Suchanek <msuchanek@suse.com> --- Can you set up kdump on the machine? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c12 --- Comment #12 from Marius Kittler <marius.kittler@suse.com> --- It looks like kdump is actually already enabled. (All packages mentioned on https://doc.opensuse.org/documentation/leap/tuning/html/book-tuning/cha-tuni... are already installed and the related checkbox in yast is checked and the kernel parameters mentioned in the bug description look like it as well). It has `/var/crash` configured as destination but unfortunately there's nothing in the directory (also not in any of `/.snapshots/*/snapshot/var/crash`). (Unfortunately the ncurses yast2 UI for the kdump config seems broken for doing any changes as one can not navigate to the right side of the menu. That bug is also present on my local TW system. Maybe I should report it separately.) Note that I only observed the kernel panic once. So I'm not sure whether it happened on all crashes. I could nevertheless try to reproduce it by booting into Leap 15.4 again. However, before doing that it would make sense to make sure the kdump setup actually works (as it doesn't seem like it). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c13 --- Comment #13 from Marius Kittler <marius.kittler@suse.com> --- Ok, the kdump config can be adjusted. I was just to stupid to use the ncurses-based UI. I now set the memory to the value recommended by the UI and also enabled "Use Firmware-Assisted Dump". Maybe these settings make a difference? Tomorrow I can try rebooting on Leap 15.4 although I'll have to clarify whether that's actually ok (as the worker is used in production). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c14 --- Comment #14 from Michal Suchanek <msuchanek@suse.com> --- fadump is not available on this Opal version. Please switch to plain kdump. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c15 --- Comment #15 from Marius Kittler <marius.kittler@suse.com> --- I disabled it again. Unfortunately I had too many other things to do today so I haven't been able to proceed with the investigation. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c16 --- Comment #16 from Marius Kittler <marius.kittler@suse.com> --- We have noticed similar problems on qa-power8-5. It seemed stable at the beginning (see my initial bug report) but at some point it crashed in the same way. I have downgraded only the kernel of qa-power8-5 to 5.8 (see https://progress.opensuse.org/issues/114565#note-43). After that qa-power8-5 seems to be stable again. So likely the kernel regression was introduced after 5.8. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c17 --- Comment #17 from Marius Kittler <marius.kittler@suse.com> --- While qa-power8-5-kvm at least doesn't crash anymore under Linux 5.8 it still doesn't operate normally. It appears that QEMU is getting stuck (and therefore openQA jobs timeout). The error message ``` ��� QA-Power8-5-kvm kernel: cma: cma_alloc: alloc failed, req-size: 512 pages, ret: -4 ``` is showing up quite often in the logs, see https://progress.opensuse.org/issues/117229#note-4. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c18 --- Comment #18 from Michal Suchanek <msuchanek@suse.com> --- So it does not say anything because it does not crash but cannot run the workload either. There are other kernel versions available from the project, maybe try a different one. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c19 --- Comment #19 from Marius Kittler <marius.kittler@suse.com> --- I'm actually wondering whether the problem still occurs on the latest kernel version. Maybe it has already been fixed so one can simply update to the latest release. However, the newest version I could find in home:tiwai:kernel:X projects is 5.18. Maybe I'll try that one unless there's a repo providing e.g. the current kernel version of TW for Leap 15.4 on PPC. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c20 --- Comment #20 from Michal Suchanek <msuchanek@suse.com> --- For TW kernel you can use Kernel:stable:Backport -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c21 --- Comment #21 from Marius Kittler <marius.kittler@suse.com> --- Unfortunately the newer kernel versions from home:tiwai:kernel:X projects aren't even installable at all on Leap 15.4 because they're conflicting with 'filesystem < 16' provided by filesystem-15.0-11.8.1.ppc64le. The kernel from the backport repo is installable so I've installed and booted into it. Let's see how well that one works. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c22 --- Comment #22 from Marius Kittler <marius.kittler@suse.com> --- Unfortunately the latest kernel is also crashing, see https://progress.opensuse.org/issues/114565#note-60. Likely unrelated, but before being able to boot I had to workaround an issue with petitboot: https://progress.opensuse.org/issues/114565#note-58 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c23 --- Comment #23 from Marius Kittler <marius.kittler@suse.com> --- It crashes in the same way on vanilla Linux 6.0.0, see https://progress.opensuse.org/issues/114565#note-62 and subsequent comments. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c24 --- Comment #24 from Marius Kittler <marius.kittler@suse.com> --- I have left qa-power8-5 on Linux 6 to still have an environment where the bug can be reproduced and that can be used for further experiments. (I have setup an automatic recovery for that host so it should be ok for us. Considering the state history of that alert/action it crashed almost once every day.) So if you need an environment for testing/investigating you could get access to that host. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c25 --- Comment #25 from Michal Suchanek <msuchanek@suse.com> --- Reproducibility once a day is not all that great. I could try to bisect building kernels locally but with this reproducibility rate it's difficult to get reliable results. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c26 --- Comment #26 from Marius Kittler <marius.kittler@suse.com> --- I know. That's also why I'm currently unsure what's best to try next. Btw, these are the kernel versions we've tried so far: * 5.3.18 (default) from Leap 15.3: the last kernel version that works reliably * 5.8.15 (default) from home:tiwai:kernel:5.8: QEMU gets frequently stuck (leading to openQA tests exceeding the timeout, so basically not able to handle the workload) * 5.14.21 (default) from Leap 15.4: frequent crashes (no recorded kernel panic, system is just stuck and needs power reset via IPMI), can otherwise handle the workload * 5.19.12 (default) from Kernel project: same as 5.14 * 6.0.0 (vanilla) from Kernel project: same as 5.14 So the problem we see as of 5.14 must have been introduced after 5.3 with possible other regressions (that then apparently have been fixed before 5.14 but potentially mask the issue we see as of 5.14). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c27 --- Comment #27 from Marius Kittler <marius.kittler@suse.com> --- I've tried some stress testing. It is definitely not hard to produce *some* crashes/hang-ups. However, I'm not sure whether these tests are very meaningful to tackle the problems we see under actual production load. You can read my comments around https://progress.opensuse.org/issues/114565#note-73 for more details. We could also still give you access to the machine (ipmi and ssh) if you want to run some tests for yourself. (If you have better ideas for stress testing that would also already be helpful.) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c28 --- Comment #28 from Marius Kittler <marius.kittler@suse.com> --- By the way, maybe these log messages relate to the fact that the PowerPC workers are just getting stuck (instead of being able to invoke kdump and reboot like the x86_64 worker I've run the same stress test on): ``` [535706993019,3] OPAL: Trying a CPU re-init with flags: 0x2 [536219455903,3] OPAL: CPU 0x409 not in OPAL ! ``` It looks like the kernel tries to do something with the CPU that needs to be done differently depending on whether the machine is running in OPAL mode or not and the kernel does it the wrong way. This is likely just bad post-mortem handling, though. The real problem is likely something different and likely not even related to the stress test I've been running. It nevertheless shows that Linux's PowerPC support doesn't seem very stable in general. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c29 --- Comment #29 from Marius Kittler <marius.kittler@suse.com> --- Now the machine powerqaworker-qam-1.qa.suse.de has started to show the same symptoms. To my knowledge it ran just fine on Leap 15.4 with the standard kernel but for some reason it is unstable now as well. It has already crashed 2 times this week. Like on the other hosts there's no useful information in the journal (see https://progress.opensuse.org/issues/120004 for the related ticket on our side). I find it quite weird that not all machines showed the symptoms directly after the upgrade to Leap 15.4. As stated in the bug description, only qa-power8-4-kvm.qa.suse.de appeared to be problematic at the beginning while qa-power8-5-kvm.qa.suse.de seemed to be stable and only showed the problem a bit later. Now a 3rd machine shows the problem. Maybe the workload has changed. (I'll investigate that.) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c30 --- Comment #30 from Marius Kittler <marius.kittler@suse.com> --- It doesn't look like the load has changed. The number of finished openQA jobs on that worker in the past days is similar to the previous weeks. Our monitoring doesn't show anything odd as well except for the gaps due to the downtime (see https://stats.openqa-monitor.qa.suse.de/d/WDpowerqaworker-qam-1/worker-dashb...). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c32 Oliver Kurz <okurz@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(marius.kittler@su | |se.com) | --- Comment #32 from Oliver Kurz <okurz@suse.com> --- (In reply to Michal Suchanek from comment #31)
What kind of hardware is powerqaworker-qam-1.qa.suse.de?
Yes, this is of course also Power8. https://racktables.nue.suse.com/index.php?page=object&tab=default&object_id=... says it's in particular IBM Power System S822LC
So far the problematic workers were POWER8 which use the old KVM code which gets very little testing upstream.
Further, the problematic workers use 'openpower' firmware. That's some specific firmware different from what most machines use, and the little testing that is done by upstream on POWER8 likely happens on different firmware that also supports PowerVM.
Finally the virtualization team does not provide any support for KVM on Power at all. Any support we have is best-effort. I don't have any POWER8 hardware capable of running KVM available.
Let me try to use this channel. Maybe we can find an answer here to a question that was never properly answered elsewhere: What do you consider the best way to run virtual machine based tests on PowerPC and how to implement that? So far we always preferred qemu based tests because we can use the same on x86_64, aarch64, ppc64le (so far) as well as even s390x. Also this way we can scale best because machines can be created on the fly based on test parameters, e.g. RAM and storage size as needed for testing. For PowerVM we have a testing "backend" but it has very limited capabilities compared to bare-metal tests, e.g. interact with pre-configured LPARs and no support to save/load virtual machine images. And implementing that would require very specific PowerVM knowledge and any solution would only be valid for PowerPC. So, what is your take on it? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c33 --- Comment #33 from Michal Suchanek <msuchanek@suse.com> --- If you want to use KVM on Power it's more likely to work on POWER9. It uses the new KVM code that upstream tests and actively develops. Nonetheless, the virtualization team does not support it, and it may be broken from time to time, and take some time until fixed. Better chances than POWR8, though. For PowerVM both HMC and Novalink is scriptable so it's very much possible to create VMs on the fly but it requires platform-specific implementation. For storage and snapshots FC storage and iSCSI storage is supported by PowerVM making it possible to move the save/restore/... functionality outside of the test machine. Either requires extra hardware, the default 4x1Gbit NIC is not great for iSCSI, and FC is not available on most machines. It's also possible to use some solution that saves/restores the system over network in a platform-independent way, and it may be of use for testing baremetal as well if it ever gets implemented. Also iSCSI can be used on most hardware. Management tools that make creating LPARs easier do exist but we did not make use of any so far, mostly because Orthos and openQA do the same thing in a crosss-platform way. It is failing on Power, though. And s390 KVM is likely not making full use of the hardware capabilities, either. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c34 --- Comment #34 from Oliver Kurz <okurz@suse.com> --- (In reply to Michal Suchanek from comment #33)
If you want to use KVM on Power it's more likely to work on POWER9. It uses the new KVM code that upstream tests and actively develops.
Nonetheless, the virtualization team does not support it, and it may be broken from time to time, and take some time until fixed. Better chances than POWR8, though.
thank you. That is helpful information.
For PowerVM both HMC and Novalink is scriptable so it's very much possible to create VMs on the fly but it requires platform-specific implementation.
For storage and snapshots FC storage and iSCSI storage is supported by PowerVM making it possible to move the save/restore/... functionality outside of the test machine. Either requires extra hardware, the default 4x1Gbit NIC is not great for iSCSI, and FC is not available on most machines.
Yes. That's right. All those ideas are good but platform-specific so an expensive investment if we would continue with that.
It's also possible to use some solution that saves/restores the system over network in a platform-independent way, and it may be of use for testing baremetal as well if it ever gets implemented.
do you mean something like calling "dd" piped to "netcat" from a live-system? Because that's what I was commonly using to deploy systems easily including Microsoft Windows XP :D
Also iSCSI can be used on most hardware.
Management tools that make creating LPARs easier do exist but we did not make use of any so far, mostly because Orthos and openQA do the same thing in a crosss-platform way. It is failing on Power, though.
And s390 KVM is likely not making full use of the hardware capabilities, either.
Well, it's working fine for years and supports saving/loading VM images which is the important factor. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 http://bugzilla.opensuse.org/show_bug.cgi?id=1202138#c35 --- Comment #35 from Michal Suchanek <msuchanek@suse.com> --- Now active maintenance of powerpc qemu has stopped upstream. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com