25.05.2010 23:43, Martin Stut wrote:
Today I installed the kvm-qemu update from 0.12.3-dfsg-4 to 0.12.4-dfsg-1.
Unfortunately I still can't start the precious accounting database
VM-guest based on NT4. I also still can't (re)install NT4 SP0.
There was no changes between 0.12.3 and 0.12.4-dfsg-1
related to this problem.
Here ist my test log:
2010-05-25: update from kvm 0.12.3-dfsg-4 auf 0.12.4-dfsg-1, normal
system start
result: BSOD
*** STOP: 0x0000001E (0xC0000005,0x8001449C,0x00000000,0x8011A95B)
KMODE_EXCEPTION_NOT_HANDLED*** Address 8001449c has base at 80010000 - hal.dll
attempt: reinstallation from CD (-boot order=dc):
result: same STOP
What do you mean? Did it work with 0.12.3-dfsg-4,
but fails with 0.12.4?
The 0x0000001E STOP is mentioned all over the 'net, it's
sort of generic error which may mean many different
things. Usually suggesting "buggy driver" or other
reasons of the same theme.
attempt: -M pc-0.10 -cpu pentium3
result: kvm_run: Exec format error, kvm_run returned -8
This one needs some attention I think.
attempt: -cpu pentium2
result: kvm_run: Exec format error, kvm_run returned -8
attempt: -cpu qemu32
result: BSOD STOP 0x0000003E
This one will not work, we discovered it already.
NT needs ,level=1 for the cpu definition.
What can I do to continue accounting on the NT4 guest even after
upgrading from kvm version 72+dfsg-5+squeeze1 (works) to something current?
Martin, please understand that it is not exactly fair to
ask this question. There's very little interest of running
old operating systems. Unless someone skilled enough will
face the same problem, or someone will hire right people
to find and fix the issue, it's unlikely to be fixed. It
is difficult to debug, and it is obvious that we're facing
bugs in windowsNT, and it's very hard to stay bug-compatible.
I'm not saying "go away", not at all. Exactly the opposite,
I'm trying to help. But I never digged this deep, so I
don't know what exactly to do.
What strategy should I follow to avoid even the slightest change of
(virtual) hardware? I thought, virtualisation was a good idea to keep
legacy systems running.
For now, I see that you need to install at least SP6 on
your winNT machine. For that, try booting it in whatever
kvm which works (maybe with -no-kvm, maybe with ,level=1,
maybe with older version - anything, but not with -no-acpi),
and apply SP6. This will - hopefully - let it to work with
current kvm-0.12, at least it works for me with any sane
-cpu I tried.
This is about 0x3e issue (invalid smp configuration). It
is a genuine bug in winNT, known and fixed in SP6.
Speaking of 0x1e, this is different issue, and I haven't
seen it here. Maybe it's original NT without any service
packs (mine has SP1 integrated into install image), I dunno.
Again, later SP may fix it as well, and again, I dunno.
In any way, installing SP6a is definitely worth a try.
But let's face it: you're walking on the edge of a blade,
and are risking to fall.
About half a year ago I inspected some organization here,
they asked what to do with their IT infrastructure. I found
some dozens of i486 and pentium-based machines running
win95 and an NT-based server, and an old MSDOS-based
accounting program using btrieve(sp) (that works over
IPX protocol). That thing does not work on win2000,
for server winNT is the latest, and for clients it's
win9x. The problem they had is that old hardware stops
working and there's nothing to replace it with, because
that software (win9x) does not work on modern hardware.
I considered using virtualisation technologies, but this
will work only for "transitional period", while they move
to a new software, so that they will be able to run
current OS and their old accounting software inside a
virtual machine.
And the more it works this way, the less chances they
have to convert their system to something current, because
there are less and less specialists available who know both
their old thing and some new, who are able to convert their
data. And it will cost more too.
The bottom line of that inspection is: move. Discussion
is welcome as of _how_, and here we've several ways,
including using kvm or whatnot, but the base does not
change: they need to move.
Yes, when using virtualisation software like kvm, it is
possible to keep running the old system. But IMHO,
the resources required to keep it working (like this one,
dealing with the old bugs) are better spent elsewhere.
Again, just IMHO, you obviously know your situation
better than me.
Thanks!
/mjt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
