I just tried repairing the install, which didn't work. Neither did
overwriting the install with a fresh one. Is there something in the img
file that remembers what it was created on? Otherwise I'm at a loss to
explain why I can't get Windows XP to run.
BTW: I also tried to create a fresh virtual machine using virt-manager
and failed. I get "Uncaught error validating install parameters:
'NoneType' object has no attribute 'set_parent'" when I try to create
any Windows XP virtual machine.
On 11/06/12 08:14 PM, Gary Dale wrote:
OK, the img that worked on my Phenom II system using qemu64 as the CPU
doesn't work on my Bulldozer system using the same CPU setting. That
would suggest that qemu64 doesn't do a complete emulation. I'm getting
something carried over from the host CPU.
-----------------
I've tried running it with various cpu models. Using virt-manager, I
get the option to "Copy host CPU configuration", which worked about as
well as kvm64, Opteron_G4 and qemu64 (i.e. didn't work - still hangs
or blue screens). Choosing Phenom gives me a start-up message that
guest CPU is not compatible with host CPU. That just about exhausts
the list of 64bit AMD processors.
When I try to set the CPU model on the remote VM to kvm64, I get an
"Error starting domain: internal error Unknown CPU model kvm64" (the
same for Operton_G4). The only models that worked were Phenom and
qemu64. However, Phenom doesn't seem to be compatible with
Bulldozer... I assume that part of the problem is the remote machine
is running Squeeze and not Wheezy, so it doesn't recognize the full
range of processors.
I've got it set to qemu64 for now. I'll copy that img to my Bulldozer
machine and see if I can run it locally.
On 10/06/12 10:13 PM, Michael Tokarev wrote:
On 11.06.2012 03:44, Gary Dale wrote:
[]
Here's the qemu/ghoswheel64.log entries for the startup of the local
copy:
2012-06-10 23:38:23.205+0000: starting up
LC_ALL=C
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
HOME=/ QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-1.0 -enable-kvm -m
2048 -smp 2,sockets=2,cores=1,threads=1 -name ghostwheel64 -uuid
68bbcceb-f8c4-6a58-9a79-c50e177f8641 -nodefconfig -nodefaults
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/ghostwheel64.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime
-no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2
-drive
file=/var/lib/libvirt/images/ghostwheel64.img,if=none,id=drive-ide0-0-0,format=raw
-device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1
-netdev tap,fd=20,id=hostnet0 -device
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:74:2f:af,bus=pci.0,addr=0x3
-chardev
pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0
-device usb-tablet,id=input0 -vnc 127.0.0.1:1 -vga std -device
intel-hda,id=sound0,bus=pci.0,addr=0x4 -device
hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5
char device redirected to /dev/pts/4
Umm. That's what I was afraid of. Most important thing, cpu type,
is not
specified at all. And there, qemu-kvm gives some mix of a pseudo-cpu
and
real host cpu to the guest.
Please try running your guest -- with -snapshot maybe -- with -cpu host
and -cpu kvm64. It might be enough. One possible reason of this issue
is that with the default pseudo-cpu, some extra CPUID levels which a
bulldozer have gets exposed to the guest but should not.
Also, you may try some specific cpu model, like -cpu phenom.
I'm confused by your statement about the physical WInXP. Granted, I
can't upgrade the mainboard and processor on a physical Windows
computer without Windows complaining but that's mainly a licensing
issue. Once the proper drivers are installed, it should work.
I'm not talking about licensing issues - even if license is at problem,
windows should at least start and display the license warning somehow.
But in practice, it occured more than once when that wasn't possible.
Maybe due to drivers - for example, once AMD CPUFREQ drivers are
installed
on windowsXP, this image can't be run on an Intel machine anymore, it
will
crash (BSOD) at boot. Sometimes the same happens when different chipset
drivers are installed (so it looks like different drivers may not be
compatible with each other). Ofcourse we don't have that case here, I'm
just trying to say that things aren't always simple.
And this is one of the reasons why I'd say installing a virtual machine
afresh on bulldozer is the first thing to do in such a situation -- to
determine if it does not work at all on bulldozer or only when installed
on pre-bulldozer.
With a virtual machine, I thought the machine pretty much stayed the
same despite differences in the host architecture.
If you explicitly specify devices, yes. But you didn't: you didn't
specify
the CPU. This makes a whole lot of a difference. And this is
exactly why
I asked for the command line (resulting, after your libvirt
translation).
Thanks,
/mjt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
