08.10.2012 18:05, Josquin DEHAENE wrote:
> I forgot to specify that VMs are managed through libvirt. Thus, the xml file
> is in libvirt definition format.
> A "virsh version" gives
Yes I understand it is libvirt. For various reasons I still can't use it
locally on my development/test machine. Besides, different versions of
libvirt may generate slightly different command lines anyway, and the
qemu/kvm command line is the only thing which matters here.
[]
> I note your advice on the virtio drivers, we have already notice the
> performance gap but we use ide for historical reasons, in the time we've
> installed those VMs the windows driver wasn't functional/stable enough for
> our windows version. According to our test and our windows sources the
> windows driver is functional since the july's stable
> release(virtio-win-0.1-30).
I see. Well, for 2k8 64 the situation is indeed a bit more difficult than
for all "less advanced" versions of windows. In particular, there are MUCH
less people who have access to win2k8 than, say, win7.
> Anyway here is the command line. An extract from "pstree -al | grep lpp-dc"
>
> kvm -S -M pc-1.0 -cpu
> core2duo,+lahf_lm,+rdtscp,+popcnt,+sse4.2,+sse4.1,+dca,+pdcm,+xtpr,+cx16,+tm2,+est,+vmx,+ds_cpl,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds
> -enable-kvm -m 2000 -smp 4,sockets=1,cores=4,threads=2 -name lpp-dc -uuid
> 9adb3d97-de75-ef46-f77f-b2b4eace3c1e -smbios type=0,vendor=moka
> pilot,version=3.0 (cluster),date=05/20/2012 -nodefconfig -nodefaults -chardev
> socket,id=charmonitor,path=/var/lib/libvirt/qemu/lpp-dc.monitor,server,nowait
> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime
> -no-shutdown -boot order=cd,menu=on -device
> piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive
> file=/dev/drbd/by-res/disk-system-dc-lpp,if=none,id=drive-ide0-0-0,format=raw
> -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive
> file=/dev/drbd/by-res/disk-datas-dc-lpp,if=none,id=drive-ide0-0-1,format=raw
> -device ide-hd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -drive
> file=/mnt/meta/src/6001.18000.080118-1840_amd64fre_Server_fr-fr-KRMSXFRE_FR_D
VD.iso,i
f
=none,id=drive-ide0-1-0,readonly=on,format=raw -device
ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev
tap,fd=18,id=hostnet0 -device
e1000,netdev=hostnet0,id=net0,mac=52:54:00:ae:09:95,bus=pci.0,addr=0x3 -chardev
pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc
0.0.0.0:23 -k fr -vga cirrus -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4
This does not look like the same VM as produced by the .xml you sent initially,
but I'm not sure. The most important part: your .xml has this:
<type arch='x86_64' machine='pc'>hvm</type>
but the command line above has -M pc-1.0. Where this "1.0" comes from?
This is the key question. If the command line really has -M pc-1.0 with
the "buggy" version of qemu-kvm, it indeed is a bug in qemu-kvm. But if
it has different version - say, pc-1.1, here, it is not a bug. This is
very important. If it is run as pc-1.1 when qemu-kvm_1.1.x is installed,
please change the .xml to specify pc-1.0 and check if your win8 boots
with that.
> Please let me know if I can help in anything, I hope not to have mistaken
> something.
There aren't many thnigs here. Yes It'd be nice to have this resolved
_provided_ it is indeed a bug in qemu/kvm. In order to verify we need
to see which args (-M pc*) gets passed to qemu. Note you can find the
complete command line somewhere in the libvirt logs too.
So the things we can check:
1) -M pc-foo - which one is used? If it is pc-1.1, change it to 1.0 and
retry.
2) If pc-1.0 works, we're all set, there's no bug. If pc-1.0 does NOT
work it IS a bug, and we can try to pinpoint it further, but in this
case I really want your help, because I don't have access to w2k8.
3) please try virtio drivers regardless of 1) and 2). This will allow
you to boot regardless of -M argument.
In order to use virtio drivers, add a new empty/dummy drive to the VM,
and connect it to virtio bus. On first boot, windows will ask for drivers -
install them. After this is done, and you rebooted and can see that
empty/dummy drive, remove it from the VM definition, and you can now
switch OTHER drives to virtio, since virtio driver is now registered
in windows properly and will be used during boot too.
The same way can be done to re-install an IDE driver - switch to virtio,
next create a dummy ide drive and let it to install drivers for that.
But for ide, a shorter path can be used - in 1.0 (working) version,
switch the IDE controller driver to "Standard/generic IDE controller",
reboot into 1.1, and let it redetect the controller. The first boot
(before redetection) will be very slow, since no good storage driver
is in use, but on next boot it should work.
This all applies to winnt4.0-win7, but I dunno if that will work on
win2k8 64bits.
> And last but not least, thank you very much for your good job.
Well, I'm trying my best, thank you for your apprecation, but sure
thing I can't have all possible guest OSes out here... :)
/mjt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
