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
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 glommer-AT-gmail.com 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: 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=detailaid=1895893group_id=180599atid=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: snip Today, I managed to get a couple Linux guests to load using the virtio drivers in kernel 2.6.25. Colour me impressed! snip 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
