Re: [Qemu-devel] --disable-gfx-check still wants SDL.h?
- Original Message - From: David Barrett [EMAIL PROTECTED] To: qemu-devel@nongnu.org Sent: 13.03.2008 4:24 Subject: [Qemu-devel] --disable-gfx-check still wants SDL.h? Is it possible to compile/run qemu on a system that does not have SDL? I assumed this is what --disable-gfx-check does, but it's still giving me errors (below). The specific error (The error log from compiling the libSDL test is) sounds like it's compiling some sort of test -- is there any way to disable test compilation? This error is actually warning, afair. Try to run `make` Sergey Bychkow ICQ: 21014758 FTN: 2:450/118.55
Re: [Qemu-devel] Slow clock in guest OS
- Original Message - From: Sergey Bychkov [EMAIL PROTECTED] To: qemu-devel@nongnu.org Sent: 25.01.2008 0:08 Subject: [Qemu-devel] Slow clock in guest OS I can't understand why clock in guest OS (Windows 2003) goes very slow. I have found that slow clock was inspired by working UltraVNC server installed in guest OS. Possibly, often queries to video driver force qemu to forget to send clock IRQs to guest. At this time I didn't find more details about this problem, but stopping UltraVNC service completely remove it. Sergey Bychkow ICQ: 21014758 FTN: 2:450/118.55
Re: [Qemu-devel] FC7 and qemu + Windows server 2003
- Original Message - From: Kaushik karandikar To: qemu-devel@nongnu.org Sent: 21 лютага 2008 7:44 Subject: [Qemu-devel] FC7 and qemu + Windows server 2003 Hi All, I am having my host OS as Fedora 7 and my guest OS is Windows Server 2003. I want to setup Network for Windows Server. I tried creating Network bridge and tap0 device. Also i tried with VDE method for network setup. Can someone please let me know what steps should i follow? Also Is it specific to Network chip. I am having RTL8201. This model is not supported with qemu. How should i go with this ? You simply should create bridge with tap device :) Assume You already have configured br0 device: # qemu -net nic,model=rtl8139,macaddr=52:54:00:80:80:01 -net tap,script=$DIR/qemu-ifup-br0,downscript=$DIR/qemu-ifdown-br0 -hda $DIR/virtw2k3 -m 384 -localtime ==start of qemu-ifup-br0== #!/bin/sh echo Configuring virtual interface $1 if [ $UID -eq 0 ] then BRIF=br0 if brctl addif $BRIF $1 then echo $1 added to $BRIF ifconfig $1 0.0.0.0 up echo $1 configured for bridge $BRIF else IP_LOCAL=169.254.1.1 echo $1 not added to $BRIF ifconfig $1 $IP_LOCAL up echo $1 configured to $IP_LOCAL \(like autoip\) # TODO: try to make real autoip fi else echo Will sudo $0 exec sudo -p Password for $0: $0 $* fi ==end of qemu-ifup-br0== ==start of qemu-ifdown-br0== #!/bin/sh #echo This script does nothing echo Deconfiguring virtual interface $1 will be done automatically ==end of qemu-ifdown-br0==
Re: [Qemu-devel] precompiled qemu-system-x86_64 is 32 bit insteadof 64bit
- Original Message - From: Andrew Warkentin [EMAIL PROTECTED] To: qemu-devel@nongnu.org Sent: 21.02.2008 10:17 Subject: Re: [Qemu-devel] precompiled qemu-system-x86_64 is 32 bit insteadof 64bit Why does it matter if it is 64-bit or not? Most programs at the moment don't benefit from being compiled 64-bit. I don't get the obsession with 64-bitness that most Linux and BSD people seem to have. I think workstation Unices like Solaris and IRIX get things right (only stuff that benefits from being 64-bit is 64-bit, the rest is 32-bit, so there is no need for separate 32- and 64-bit versions of the system, and fewer compatibility issues). Just to clarify: I'm referring to the QEMU binary itself, not the architecture it emulates. Symply saying: if You can execute downloaded binary on Your host, then it is suitable for You :) However You should compile kqemu kernel module if You want to use it. Sergey Bychkow ICQ: 21014758 FTN: 2:450/118.55
Re: [Qemu-devel] precompiled qemu-system-x86_64 is 32 bit instead of 64bit
- Original Message - From: Ralf Baerwaldt [EMAIL PROTECTED] To: qemu-devel@nongnu.org Sent: 19.02.2008 18:09 Subject: [Qemu-devel] precompiled qemu-system-x86_64 is 32 bit instead of 64bit I downloaded http://fabrice.bellard.free.fr/qemu/qemu-0.9.1-i386.tar.gz and I'm using an AMD Opteron. Is this version the correct one for my system ? If You want qemu for your amd64 linux system, You should compile it yourself or install from Your linux distribution repository. This site (http://fabrice.bellard.free.fr/qemu/download.html) doesn't contain precompiled linux binaries except for i386 platform. However You could execute i386 binaries on amd64 linux platform. :) Sergey Bychkow ICQ: 21014758 FTN: 2:450/118.55
Re: [Qemu-devel] More about slow clock in guest OS
- Original Message - From: Mulyadi Santosa [EMAIL PROTECTED] To: qemu-devel@nongnu.org Cc: [EMAIL PROTECTED] Sent: 1.02.2008 4:41 Subject: Re: [Qemu-devel] More about slow clock in guest OS After some investigations I can say that with the latest (2008/01/30) qemu from cvs, compiled with gcc-3.4 on linux x86_64 host, guest OS win2k3 works not too good. So, in other words it works but not so well. may I interpret it as a progress? Yes, now there is a choice: stable but slow (dynticks) and unstable but faster (rtc) Unfortunately, there is no option stable and correct yet ;) With -clock dynticks clock in OS is very slow - and windows time server can't adjust. Probably due to cost of Qemu timer rearming. And maybe Windows 2003 does certain dyntick by its own...thus enlarging the timer rearming cost. Tests say that in dynticks mode clock in VM is 4-5 times slower than in real world. With -clock rtc hung periodically - for up to 5 minutes, 300 seconds. p... too much timers get expired? lock contention somewhere...anybody? I even stop experiments with rtc because of instability. Maybe somebody else will find this problem in the future, I'm focusing in testing dynticks mode now. Thus..maybe it's Qemu's fault... sudo $QEMU -net nic,model=rtl8139,macaddr=52:54:00:80:80:01 -net tap,script=$DIR/qemu-ifup-br0,downscript=$DIR/qemu-ifdown-br0 -localtime -cdrom /distrib/knoppix/KNOPPIX_V5.1.0CD-2006-12-30-EN.iso -m 384 -pidfile $DIR/virt1-knoppix.pid -smp 1 -no-kqemu -clock rtc -vnc :9 Ehm: 1. can you simply use SDL output instead of VNC? 2. what if you don't use -localtime? just courious... 1. Yes, but main purpose is to run VM on linux server, without X. 2. The only difference is that initial clock is two hours out. Windows always assumes that hardware clock is local. == $ cat /proc/sys/dev/rtc/max-user-freq == 4096 == ehm...I think 1024 is enough for most cases.. There were tests, and this parameter doesn't affect dynticks mode, so now it is in default value, 64. $ uname -a == Linux *** 2.6.18-5-amd64 #1 SMP Sat Dec 22 20:43:59 UTC 2007 x86_64 GNU/Linux == is that kernel version of the host? can you upgrade it ? let's say to the latest 2.6.24? I will upgrade it when Debian releases next stable release :) PS: could you try KVM too? but ehm...well, sounds like you don't have VT enabled Intel processor or SVM enabled AMD processor. So, if you indeed have one...try KVM.. At this time I apply some weird combination of standard and self-made tools to keep clock in VM in sync with outer world. May be I will try to compare behaviour of different OSes in qemu and/or KVM. Sergey Bychkow ICQ: 21014758 FTN: 2:450/118.55
Re: [Qemu-devel] Problems with dynticks clock
- Original Message - From: Victor Shkamerda [EMAIL PROTECTED] To: qemu-devel@nongnu.org Sent: 4.02.2008 14:09 Subject: [Qemu-devel] Problems with dynticks clock Any DOS game that I've tried eventually hangs the QEMU. GDB shows that QEMU is running in infinite loop in translated basic block and does not respond to any keyboard or mouse events... If I start QEMU with rtc or unix clock this does not happen, or at least I never managed to trigger it. Looks that I had such problem, but only with rtc and unix clock, not with dynticks. Did You find any solution? Sergey Bychkow ICQ: 21014758 FTN: 2:450/118.55
[Qemu-devel] More about slow clock in guest OS
- Original Message - From: Mulyadi Santosa [EMAIL PROTECTED] To: qemu-devel@nongnu.org Sent: 26.01.2008 16:25 Subject: Re: [Qemu-devel] Slow clock in guest OS Sorry, did You mean http://fabrice.bellard.free.fr/qemu/qemu-tech.html; or what? yep...that's the one... As I can see, this document anything about what to do if qemu hung :) After some investigations I can say that with the latest (2008/01/30) qemu from cvs, compiled with gcc-3.4 on linux x86_64 host, guest OS win2k3 works not too good. With -clock dynticks clock in OS is very slow - and windows time server can't adjust. With -clock rtc hung periodically - for up to 5 minutes, 300 seconds. This could happen at bootstrap - when no OS, only BIOS. Then it resumes and works for some random period of time, then hangs again, and so on. This behaviour doesn't depend on guest OS, and was reproduced with Knoppix live CD. Note that host should be periodically busy executing something like torrent client. Details and startup scripts: $ cat knoppix-qemu-nographic.sh == QEMU=$HOME/bin/qemu-system-x86_64 [ -x $QEMU ] || QEMU=/usr/bin/qemu-system-x86_64 sudo modprobe kqemu echo will use executable $QEMU DIR=`dirname $0` [ -z $DIR -o $DIR == . ] DIR=`pwd` echo DIR is $DIR PREV_RTC_FREQ=`cat /proc/sys/dev/rtc/max-user-freq` [ $PREV_RTC_FREQ -ge 1024 ] || echo 'WARN: RTC FREQ too slow:' $PREV_RTC_FREQ sudo $QEMU -net nic,model=rtl8139,macaddr=52:54:00:80:80:01 -net tap,script=$DIR/qemu-ifup-br0,downscript=$DIR/qemu-ifdown-br0 -localtime -cdrom /distrib/knoppix/KNOPPIX_V5.1.0CD-2006-12-30-EN.iso -m 384 -pidfile $DIR/virt1-knoppix.pid -smp 1 -no-kqemu -clock rtc -vnc :9 == $ cat qemu-ifup-br0 == #!/bin/sh echo Configuring virtual interface $1 if [ $UID -eq 0 ] then BRIF=br0 if brctl addif $BRIF $1 then echo $1 added to $BRIF ifconfig $1 0.0.0.0 up echo $1 configured for bridge $BRIF else IP_LOCAL=169.254.1.1 echo $1 not added to $BRIF ifconfig $1 $IP_LOCAL up echo $1 configured to $IP_LOCAL \(like autoip\) # TODO: try to make real autoip fi else echo Will sudo $0 exec sudo -p Password for $0: $0 $* fi == $ cat qemu-ifdown-br0 == #!/bin/sh BRIF=br0 ifconfig $1 brctl show $BRIF brctl showmacs $BRIF echo Deconfiguring virtual interface $1 will be done automatically == Bridge interface should be configured in system $ cat /etc/network/interfaces == #auto eth0 - this interface should not be configured iface eth0 inet static ... # The primary network interface - now in bridge mode auto br0 iface br0 inet static bridge_ports eth0 ... == $ cat /proc/sys/dev/rtc/max-user-freq == 4096 == $ uname -a == Linux *** 2.6.18-5-amd64 #1 SMP Sat Dec 22 20:43:59 UTC 2007 x86_64 GNU/Linux == $ cat /proc/cpuinfo == processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 6 model name : Intel(R) Pentium(R) D CPU 2.80GHz stepping: 4 cpu MHz : 2800.000 cache size : 2048 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 6 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr lahf_lm bogomips: 5633.18 clflush size: 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 ... == $ ~/bin/qemu-system-x86_64 QEMU PC emulator version 0.9.1, Copyright (c) 2003-2008 Fabrice Bellard ... == May be somebody will understand what's happen :) Sergey Bychkow ICQ: 21014758 FTN: 2:450/118.55
Re: [Qemu-devel] Slow clock in guest OS
- Original Message - From: Mulyadi Santosa [EMAIL PROTECTED] To: qemu-devel@nongnu.org Sent: 25.01.2008 5:11 I can't understand why clock in guest OS (Windows 2003) goes very slow. Are you sure the rtc freq has been made to 1024? # cat /proc/sys/dev/rtc/max-user-freq should yield 1024 before you ran qemu. If yes, then we should hunt into another possibilities... Yes, it helps, in some extent. With rtc/max-user-freq set to 1024 and -clock rtc option VM now works like in 0.8.2 version. Clock is slower than in host, but Windows Time server could correct this, if started. Busy host or guest CPU slows down clock. Sometimes VM hangs on start. Htop shows that qemu uses 100% of second CPU in user mode. Internal QEMU VNC server listens port but doesn't accepts connections, so vncviewer hangs too. If used GUI, is shows monitor prompt, that doesn't accept any keyboard input. Could be killed by Ctrl-C in console or 'kill -9'. May be it's different problem but they happen both on the same host hardware. Sergey Bychkow ICQ: 21014758 FTN: 2:450/118.55
Re: [Qemu-devel] Slow clock in guest OS
Sometimes VM hangs on start. ^^ this is weird can you dump the generated opcode? pls see qemu-doc/tech for more detail on how to do it. Sorry, did You mean http://fabrice.bellard.free.fr/qemu/qemu-tech.html; or what? Sergey Bychkow ICQ: 21014758 FTN: 2:450/118.55
Re: [Qemu-devel] Slow clock in guest OS
- Original Message - From: Mulyadi Santosa [EMAIL PROTECTED] To: qemu-devel@nongnu.org Sent: 25.01.2008 14:02 Yes, it helps, in some extent. With rtc/max-user-freq set to 1024 and -clock rtc option VM now works like in 0.8.2 version. Clock is slower than in host, but Windows Time server could correct this, if started. Busy host or guest CPU slows down clock. I remember somebody wrote dyntick patch...but not sure if it is already merged into qemu CVS. Yes, it merged (I thought it is the default). Now I tried to test VM with it - Win2k3 hangs on boot, on the stage, afaik, switching to protected mode. Maybe you need similar trick like win98 to halt CPU when not doing anything? Win2k3 has NT kernel (like in WinXP/2000) and does't require this. When guest OS is idle, qemu uses only few percents of host CPU, and guest clock didn't lose too much. Sometimes VM hangs on start. ^^ this is weird can you dump the generated opcode? pls see qemu-doc/tech for more detail on how to do it. May be I will try to work with this problem later and report it in different thread. Htop shows that qemu uses 100% of second CPU in user mode. Before I forgot, do you use kqemu? if yes, do you full virtualization mode? Yes. No. But I have got this problem sometimes with -kernel-kqemu and with -no-kqemu options. Internal QEMU VNC server listens port but doesn't accepts connections, so vncviewer hangs too. If used GUI, is shows monitor prompt, that doesn't accept any keyboard input. Could be killed by Ctrl-C in console or 'kill -9'. May be it's different problem but they happen both on the same host hardware. very weirddo you use precompiled qemu binary? or do you compile by yourself? if it is compiled by yourself, what gcc version do you use? Previous (stable) version of qemu 0.8.2 was from Debian Etch amd64 (x86_64) - precompiled. Yesterday's snapshot (qemu-snapshot-2008-01-24_05) compiled manually with GCC-4, for targets x86_64-softmmu, i386-softmmu. == $ ./configure --disable-gcc-check --disable-gfx-check --target-list=i386-softmmu x86_64-softmmu --prefix=$HOME make make install == qemu-system-x86_64 only used, because host OS is x86_64 and I want kqemu to be used. Win2k3 is 32bit version. PS There is no documentation about -clock option in latest qemu documents, exept source code, of cause :) Yours sincerely, Sergey Bychkow ICQ: 21014758 FTN: 2:450/118.55
[Qemu-devel] Slow clock in guest OS
Hi! I can't understand why clock in guest OS (Windows 2003) goes very slow. Host OS: Debian GNU/Linux Etch x86_64 (kernel 2.6.18.5-amd64) Host CPU: something like Intel Core Duo $ cat /proc/cpuinfo processor : 0 # and 1 too vendor_id : GenuineIntel cpu family : 15 model : 6 model name : Intel(R) Pentium(R) D CPU 2.80GHz stepping: 4 ... qemu version: snapshot 24.01.2008, compiled with GCC 4 for target x86_64-softmmu Stable version in Debian Etch is 8.2 works not very stable - but clock get lost only sometimes, when host CPU is busy. Snapshot works more stable - clock is constantly slow, even M$ NTP server (Windows Time) can't help. I can't find, how to debug this problem. Sergey Bychkow ICQ: 21014758 FTN: 2:450/118.55
Re: [Qemu-devel] [RFC][PATCH] Modify loop device to be able to managepartitions of the image disk
All comments are welcome, perhaps it is stupid idea... Exellent thing. I wonder why loop device in linux kernel haven't this functionality yet. Don't You think to try to add this patch to linux kernel source tree? Sergey Bychkow ICQ: 21014758 FTN: 2:450/118.55
Re: [Qemu-devel] QEMU problem ...
- Original Message - From: dara burke [EMAIL PROTECTED] To: qemu-devel@nongnu.org Sent: 6.12.2007 1:24 Subject: [Qemu-devel] QEMU problem ... I've got a problem with Qemu, it won't seem to work on my ubuntu system. It can't seem to find the framebuffer device ... [EMAIL PROTECTED]:~/qemu_dir$ qemu -localtime -cdrom /dev/cdrom -m 384 -boot d c.img (!) DirectFB/Core: Could not initialize 'system' core! Could not initialize SDL - exiting Does anyone have any ideas ? Possibly, You try to execute it without X? Or, try to execute it as root Sergey Bychkow ICQ: 21014758 FTN: 2:450/118.55
Re: [Qemu-devel] Re: multiple virtual network with qemu
- Original Message -
From: nik600 [EMAIL PROTECTED]
To: qemu-devel@nongnu.org
Sent: 7.12.2007 11:14
Subject: [Qemu-devel] Re: multiple virtual network with qemu
any idea?
[skip]
Or if it possible
- gw (192.168.1.1)
| - hosting machine (192.168.1.2)
| - virtual ip (192.168.1.3) - emulated system 1
(192.168.1.3)
| - virtual ip (192.168.1.4) - emulated system 2
(192.168.1.4)
Can i do that?
Yes. First You should configure bridge interface
in Debian it looks like:
== start of /etc/entwork/interfaces ==
#auto eth0 - do not configure eth0
iface eth0 inet static
# The primary network interface - now in bridge mode
auto br0
iface br0 inet static
bridge_ports eth0
address 192.168.1.2
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
=== end of /etc/entwork/interfaces ===
Do not forget `apt-get install bridge-utils`
Then make qemu-ifup-br0 instead of standard qemu-ifup
== start of ./qemu-ifup-br0 ==
#!/bin/sh
# brctl addbr br0
echo Configuring virtual interface $1
if [ $UID -eq 0 ]
then
ifconfig $1 0.0.0.0 up
if brctl addif br0 $1
then
# bridge exists and could be configured
echo $1 added to br0
ifconfig $1 0.0.0.0 up
echo $1 configured for bridge
else
# fallback - no bridge configured
echo $1 not added to br0
ifconfig $1 169.254.1.1 up
echo $1 configured to autoip
fi
else
echo Will sudo $0
exec sudo -p Password for $0: $0
fi
=== end of ./qemu-ifup-br0 ===
Then start every VM with options
QEMU=/usr/bin/qemu # or something else
sudo $QEMU -net nic,model=rtl8139,macaddr=52:54:00:80:80:0N -net
tap,script={$path_to_qemu_ifup_br0} -localtime -hda imageN -m 384
Where N is (1,2,etc)
BTW, this script could be included in installation
Sergey Bychkow
ICQ: 21014758
FTN: 2:450/118.55
