Re: Live memory allocation?
On Saturday 28 March 2009 11:17:42 am you wrote: > KVM devs have a patch called KSM (short for kernel shared memory I think) > that helps windows guests a good bit. See the original announcement [1] > for some numbers. I spoke to one of the devs recently and they said they > are going to resubmit it soon. I remember the discussion about KSM. First, the kernel developers were not very happy with the approach, and second, there were some patent implications with VMware. Have these issues been resolved? Don't get me wrong. I'm not trying to stop KSM, I'm just wondering if I can get my hopes up again. I thought KSM was a great idea and I'd love to get my hands on it. -- Alberto Treviño BYU Testing Center Brigham Young University -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Live memory allocation?
On Thursday 26 March 2009 08:11:02 am Tomasz Chmielewski wrote: > Like, two guests, each with 2 GB memory allocated only use 1 GB of > host's memory (as long as they don't have many programs/buffers/cache)? > > So yes, it's also supported by KVM. The problem I've seen with this feature is that Windows guests end up taking all of their available memory once they are up and running. For example, booting Windows XP in KVM 82 show a steady increase in memory. Then about the time the login box is about to appear, memory usage jumps to the maximum allowed to the VM (512 MB in this case). I remember reading somewhere Windows would try to initialize all memory during boot, causing KVM to allocate all memory. VMware, however (and I don't know about VirtualBox) knows about this and works around it, making sure memory isn't all allocated during the Windows boot process. Would there a way to work around the Windows memory allocation issue in KVM as well? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can i shrink the image file size?
On Saturday 21 March 2009 10:45:58 am John Wong wrote: > I create the 30G qcow2 image file, installed winxp, winxp show me the > harddisk used 5G, but the image file size is 12G now. > can i shrink the image file size? how? I wrote a simple utility in .Net 2.0 that creates a file in Windows with all 0's until the drive is full, then deletes it. This allows qemu-img to recreate the image and reclaim any sectors that are all 0's. This is what I do: 1. Defragment the Windows drive(s). Run the defragmenter at least 3 times to make sure you get good results. 2. Run my tool (http://mel.byu.edu/zerofill.exe). It will automatically detect all drive letters, create a file filled with zero's and delete it whn it's done. Make sure the VM is not under a lot of use or the continually decreasing amount of disk space may interfere with whatever may be running. 3. Run qemu-img and recreate the virtual drive with the same format parameters. For example, if your image is in qcow2 format you run: qemu-img convert -O qcow2 win_xp.img win_xp.img.new 4. Rename win_xp.img to win_xp.img.old and win_xp.img.new to win_xp.img. Run your VM and make sure everything works. If it does, remove win_xp.img.old and go on with life. I would recommend you back up your drive image before your start the first couple of times, just to be sure. It's not fun when you screw up and can't get back into your VM. I've done that a few times while developing this technique. :-) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: howto control VM from outside (shutdown...)
On Monday 19 January 2009 02:40:04 pm David Mair wrote: > Take a look at the qemu -monitor option. You can use it to re-direct the > monitor console to a large number of character devices, including > sockets. The settings are the same as for the -serial option. I've used > it to access the monitor console from a telnet client. I use the the telnet option: -monitor telnet::[port],server,nowait For interactive control I use telnet: $ telnet localhost [port] and I can connect to it to run any commands I want. Just be aware that you should exit with Ctrl-C or by making sure you are at the telnet prompt when you issue quit. If you issue quit to the VM, the entire VM will shutdown very, very quickly and ungracefully. To send commands through a script, I use netcat: echo "system_powerdown" | netcat -T -c localhost [port] I also have a PHP script that opens a socket connection to the telnet port, sends the command, and parses the output for errors. I'll be happy to share it. Let me know if you want it. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is ntpd in guest necessary?
On Sunday 16 November 2008 07:27:48 am you wrote: > In theory, CONFIG_KVM_CLOCK should avoid the need for ntp. Let us know > if you get different results. I've been running a VM for a couple of days with a 2.6.27 kernel and CONFIG_KVM_CLOCK and the clock is synchronized. Is there a driver we could use on Windows to keep the clock synchronized there as well? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] kvm-78 release
On Sunday 02 November 2008 01:39:41 am Avi Kivity wrote: > Changes from kvm-77: > - merge qemu-svn >- new live migration implementation >- migration fixes Can anyone tell me if these migration fixes now allow for live migration of VM's with more than 4 GB of RAM? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Avoiding I/O bottlenecks between VM's
On Friday 19 September 2008 12:41:46 pm you wrote: > Are you using filesystem backed storage for the guest images or direct > block device storage? I assume there's heavy write activity on the > guests when these hangs happen? Yes, they happen when one VM is doing heavy writes. I'm actually using a whole stack of things: OCFS2 on DRBD (Primary-Primary) on LVM Volume (continuous) on LUKS-encrypted partition. Fun debugging that, heh? In trying to figure out the problem, I tried to reconfigure DRBD to use Protocol B instead of C. However, it failed to make the switch and both nodes disconnected so now I have a split-brain. In try to fix the split brain I'm taking down on one node all the VM's one by one, copying the VM drives from one node to the next, and starting up on the other node (old- fashioned migration). Yes, I'm having *lots* of fun! Perfect way to end the week! So, any ideas on how to solve the bottleneck? Isn't the CFQ scheduler supposed to grant every processes the same amount of I/O? Is there a way to change something in proc to avoid this situation? -- Alberto Treviño BYU Testing Center Brigham Young University -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Avoiding I/O bottlenecks between VM's
I am using KVM 69 and kernel 2.6.25.17 to host several VM's in a large server. So far, everything has been great. Except I'm adding a Windows Server VM that will run a SQL Server database. A few times I've noticed that I/O becomes a bottleneck for the VM and Windows VM freezes for a few seconds. Oh well, no biggie. Except, every so often, these I/O bottlenecks start to affect other VM's and they freeze as well for a few seconds. I don't really care of one VM does so much I/O that it freezes itself temporarily. I just don't want I/O bottlenecks on one VM to affect other VM's. My questions are: 1. Is this a problem anyone else has experienced and has it been fixed in a later KVM release? 2. I'm using the CFQ scheduler. Would the deadline scheduler do a better job? 3. Any other suggestions to improve this problem? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Un-googlable
On Saturday 16 August 2008 06:45:55 pm David Abrahams wrote: > on Sat Aug 16 2008, "Glauber Costa" wrote: > Really, everyone types out that long phrase when asking questions? No, I type "kernel kvm" or do "kvm -switch" to remove pages that talk about KVM switches. I have also thought the name to be unfortunate, but you just need to ask Google a better question. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM Management : Public Bridge setup
On Friday 08 August 2008 08:18:26 pm jd wrote: > The /etc/qemu-if script seems to be taking the interface as a > parameter, is there a way to pass the bridge name to the script as well. > Thus from the command line one can pass the bridge that one whats to > attach to. (One can potentially one script for each bridge and pass the > script name to qemu... but it seems bit unnecessary.) I name my tap devices (using ifname=...) as follows: tap.br0.05.1 where tap -- this is a tap device br0 -- the name of the bridge 05 -- the ID of the VM (each of my VM's has a unique numeric ID) 1-- The NIC # on the VM (1, 2, 3, or 4 depending on # of NIC's) Then on my scripts I can extract the bridge name and use it. This also has the advantage of helping me know just by the name what bridge this devices is hooked up to, what VM it belongs to, and which NIC it is inside the VM. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fresh install of Windows XP hangs early in boot?
On Tuesday 29 July 2008 04:00:06 pm Roland Dreier wrote: > I'd be willing to take a stab at a better fix. Thanks, Roland for volunteering. I has been nearly 10 years since I worked on low-level hardware programming and I figured it would take me too long just to become familiar with SCRIPTS, then try to figure out the Windows "black box". That's why I haven't taken a stab at it. However, I'd be more than happy to test any patches you may have. I have a couple of development environments where I could play around and test any fixes. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fresh install of Windows XP hangs early in boot?
On Tuesday 29 July 2008 01:39:53 pm you wrote: > I built with debugging symbols, and this seems to be an issue with SCSI > disk emulation. The problem might be related to this bug report: http://sourceforge.net/tracker/index.php?func=detail&aid=1895893&group_id=180599&atid=893831 Marcelo Tosatti worked hard on getting the bug fixed, but the patch was rejected by the Qemu team because it was not a "proper" fix. Marcelo has been trying to figure out what a proper fix should look like and rework the patch. I don't know what Marcelo's progress has been on the issue. The last working patches Marcelo and others put out which fixes the lock-ups can be found here: http://slim.mypals.org/slim/files/kvm/kvm-64-scsi.patch http://slim.mypals.org/slim/files/kvm/lsi-busy-loop-3a.patch You may try installing those patches on KVM (they can still be applied to KVM-72) and see if they fix your problems. Hope this helps. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Colour me impressed: 2.6.25, kvm-69, virtio_net
On Wednesday 04 June 2008 03:51:12 pm you wrote: > Today, I managed to get a couple Linux guests to load using the > virtio drivers in kernel 2.6.25. Colour me impressed! > That, combined with how easy it is to manage kvm (I wrote my own > management scripts and config file format that is a lot easier to > read than the Xen ones), configure networking in the host (done using > the distro tools, not some arcane python scripts), and get hardware > driver support in the host (standard distro kernels, not ancient > xen-specific ones), makes it very hard to find reasons to run Xen. > The only reason I can find, is if you have hardware that doesn't > support VMX/SVM, but is supported by kernel 2.6.18, in which case Xen > 3.0 works quite nicely (not 3.1 or later). > > Kudos to the kvm devs, the kernel devs, the qemu devs, and the rest > who are involved in making KVM work so well! I agree. I've been really impressed with KVM-69. It has worked very reliably. My story is very similar, except that I was using the free VMware Server (I couldn't justify the price tag for ESX). In short, KVM came to save the day and I get much better performance than I did with VMware. My setup is for a two-node cluster with DRBD and OCFS2. The ability to migrate VM's so quickly is wonderful. I too wrote my own scripts which I will share in a few months once I'm done fixing bugs. Yes, KVM is very easy to install, manage and use. It is even better when you write your own scripts. It's wonderful to be able to manage things in a way that best makes sense based on your experience and infrastructure. Thank you to the KVM team for all of your great work! -- Alberto Treviño [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with GRUB and boot=on flag
On Thursday 22 May 2008 06:46:49 pm Anthony Liguori wrote: > How did you install grub on this drive? Is this a distro image or > did you install grub yourself? I compiled GRUB from source, and installed to the MBR as normal. You can download a CD image that boots with GRUB from: http://mel.byu.edu/slim-cd-v4.iso If I boot from that CD, I get the same crash. -- Alberto Treviño [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Problems with GRUB and boot=on flag
I am having a really weird problem. I reported about it earlier (see http://article.gmane.org/gmane.comp.emulators.kvm.devel/15884) thinking the problem was with SCSI disks, but that's not the case. Let me try to explain. I have a drive that has GRUB and Linux. If I run the following command, it boots normally, even though the boot flag has been set to off: qemu-system-x86_64 -m 256 -drive file=hd0.qcow2,if=ide,bus=0,index=0,media=disk,boot=off If I run the following, qemu crashes when GRUB loads: qemu-system-x86_64 -m 256 -drive file=hd0.qcow2,if=ide,bus=0,index=0,media=disk,boot=on Qemu reports the following when it crashes: exception 13 (33) rax rbx 0800 rcx rdx 00e0 rsi 7d98 rdi 0008f788 rsp 2018 rbp 0001 r8 r9 r10 r11 r12 r13 r14 r15 rip 0003 rflags 00033202 cs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es 0800 (8000/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) gs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) tr (fffbd000/2088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt fb1f2/30 idt 0/3ff cr0 10 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 code: 53 ff 00 --> f0 53 ff 00 f0 53 ff 00 f0 53 ff 00 f0 53 ff 00 f0 53 ff 00 f0 53 ff 00 f0 53 ff 00 f0 a5 fe 00 f0 87 e9 00 f0 53 ff 00 f0 53 ff 00 f0 53 ff Aborted If I change the interface to SCSI and set the boot flag to off, Qemu can't find a valid boot drive and does not boot. If I change the interface to SCSI and set the boot flag to on, I get the same crash. According to Anthony Liguori's original extboot post, "boot=on" turns on the extboot code, so my problem is the combination of extboot and GRUB. A response on my original post suggested this might be a real mode issue. However, it seems more of an extboot problem with some of the calls from GRUB. What's the status of the extboot in C project? Perhaps I could try that to see if it fixes the problem. Does anyone have any other suggestions? -- Alberto Treviño [EMAIL PROTECTED] Testing Center Brigham Young University -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
