Missing symlink in qemu-kvm.git?
When building on x86 I get this error: make[2]: Entering directory `/home/wa1ter/src/qemu-kvm/kvm/libkvm' make[2]: *** No rule to make target `/home/wa1ter/src/qemu-kvm/kvm/kernel/include/asm/kvm.h', needed by `libkvm.o'. I fixed it by adding the same symlink that I add to Linus's kernel.git for exactly the same reason: #cd qemu-kvm/kvm/kernel/include #ln -s ../arch/x86/include/asm asm [there was no asm directory here] Am I the only one who has this problem? Thanks! -- 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: qemu-kvm.git now live
Avi Kivity wrote: After a lengthy testing phase, qemu-kvm.git has replaced kvm-userspace.git as the source repository for kvm userspace development. Differences from kvm-userspace.git are as follows: - everything under qemu/ has been moved to the top-level directory - everything not under qemu/ has been moved under a new top-level directory, kvm/ - all qemu subversion commits have been rewritten to be compatible with what will become the master qemu git repository - all branches and tags have been converted - qemu-kvm.git builds standalone (does not require kvm.git) The repository is compatible with upstream qemu.git; merges and cherry-picking will work fine in either direction Still missing: - I have not tested powerpc or ia64. Patches welcome! - testsuite (kvm/user/ directory) does not build git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git I just tried running configure on x86 and amd_64 and I got no kvm support (field 'arch' has incomplete type). Is this the expected result? Just for fun I also tried running configure in the top-level kvm directory and got thousands of unkillable 'configure' processes that quickly filled my 1-gig swap partition. I doubt that's the expected result :-) -- 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: kvm-82
Gioacchino Mendola wrote: Hello everyone, I hope my questions will not be too trivial! I downloaded and compiled KVM-82 but I have trouble loading the modules.The message error is as follows: insmod: error inserting 'kvm.ko': -1 Unknown symbol in module Why can not I load the modules? p.s i use kernel 2.6.28 Where did you get kvm.ko? It should come from the same sources your kernel is compiled from, and you should compile KVM using the --with-patched-kernel flag for the configure step. That is, kvm.ko should come from your kernel source code and not your KVM-82 sources. -- 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: KVM-82 failed to compile
Simon Gao wrote: Carlo Marcelo Arenas Belon wrote: has your kernel configuration (/usr/src/linux/.config) the following enabled? CONFIG_MMU_NOTIFIER=y I did not see the config parameter in my .config file, only has: CONFIG_MMU=y # CONFIG_IOMMU_HELPER is not set Is there other parameter to enable to see the option? Do 'make menuconfig' and select the second item from the bottom: Virtualization--Kernel-based Virtualization (KVM) support. -- 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: 'make' is no longer producing *.ko files?
On Tue, 30 Dec 2008, Michael Park wrote: Hello, I'm running into a strange problem of 'make' not producing any *.ko files recently (kvm-82). This seems rather odd, as 'make' still completes successfully (echo $? returns 0), and there are *.o files that are output as a result. I've done a paste of my ./configure and make steps here: http://rafb.net/p/BKK6yH11.html [emp...@bart:~]$ uname -a Linux bart.localdomain 2.6.27.9-73.fc9.x86_64 #1 SMP Tue Dec 16 14:54:03 EST 2008x86_64 x86_64 x86_64 GNU/Linux [emp...@bart:~]$ cat /etc/issue Fedora release 9 (Sulphur) Kernel \r on an \m (\l) Has anyone seen this behavior before? (I successfully compiled kvm-79, kvm-80, and kvm-81, however recently I've noticed that this problem is occurring when I try to build those previous kvm releases as well. Is this a Fedora kernel-devel problem? Just curious -- have you not been using the kvm modules included with the linux kernel? (I'm assuming you mean kvm.ko and friends?) -- 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
FreeBSD guest on Linux host: console screen corruption?
Hi, I'm tracking kvm.git on a linux host, current as of today. I've been playing with FreeBSD as guest and I'm seeing very annoying problems with console screen corruption which makes it almost impossible to use. The corruption consists of patches of screen output where every other character is blacked out, i.e. invisible. Depending on what I'm trying to do, sometimes the console output looks normal, sometimes not. FreeBSD uses an ncurses-based install program that's illegible about half the time on kvm because of this problem. This intermittent problem with every-other-character being invisible makes me think of some UTF-8 kind of problem, maybe? Just a guess, I really have no idea. Changing from -vga cirrus to vmware to std make no difference. Setting LC_ALL to en_US.UTF-8 also makes no difference. Setting TERM=vt100 or vt220 does change the nature of the screen corruption, but it's still not even remotely usable. I don't see this problem when installing OpenBSD or gentoo linux (my usual distribution). I haven't tried NetBSD yet -- that's tomorrow. Meanwhile, any ideas what's causing this FreeBSD screen problem? Anyone else seen it? Thanks! -- 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: Keyboard issues with KVM-80
Mark Bidewell wrote: I just tried KVM-80, am I am running into keyboard issues. The arrow keys to not function properly and using a CentOS5 guest the up arrow brings up the Save screenshot dialog in gnome. That annoying screenshot problem is caused by the evdev driver in xorg. I fix it by deleting the evdev driver :o) I have yet to hear anyone explain what problem evdev is supposed to solve. For lots of people it just creates the problem you describe. -- 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: [Qemu-devel] qemu-img commit -- is there a limit on file sizes?
On Mon, 1 Dec 2008, Avi Kivity wrote: Anthony Liguori wrote: We've started getting some reports of corruption on commit in KVM. There is a long standing disk corruption issue too that is very difficult to reproduce. The thinking is that there is a bug somewhere in the qcow2 code. Is anyone actively looking into this? I am, though my actively is a lot less than could be desired. Additional eyes would be welcome. FWIW, I must apologize for giving you incorrect data. I'm seeing problems now that have nothing to do with the size of the commit, and I'm beginning to suspect that the commit step has nothing to do with the problem. I'll summarize my evidence because it seems potentially very important: I installed WinXP on qcow2, which went perfectly. I rebooted multiple times with no problems and changed settings for my desktop and taskbar, rebooted again with no problems. Now, I make a new, fresh [what's the opposite of a backing file?] like this: $qemu-img create -f qcow2 -b kvmXP kvmXP.delta All I do is boot XP again like this: $qemu-system-x86_64 -m 1000 kvmXP.delta My shock is that one of the taskbar settings I changed has disappeared! I can boot the original kvmXP qcow2 image and verify that my changes are still there in the original, but not when I boot kvmXP.delta. In case someone wants to try to reproduce it, the specific change I made to the task bar is to display the animated network activity icon in the system tray. That icon never appears when I boot from kvmXP.delta. In other words, from the instant I boot kvmXP.delta, the image of XP that gets loaded into memory is not an accurate reflection of what's in the backing file. If that's true, then it's not surprising that the commit step causes trouble. Does my reasoning seem reasonable? :o) -- 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: Is this a bug in qemu-img?
walt wrote: ... BTW, I've been through the same steps twice and get the same results, so I don't think it's flakey hardware. OTOH today is a new day, so I'll try it again to triple check. Tried again all the way from the beginning and got the same result. The commit step is where things go wrong every time. I know qcow2 is not considered quite ready for prime time, but having that commit feature is important to me so I'd love to see it work correctly. Any chance that 'commit' could be added to raw as well as qcow2? Thanks. -- 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: Is this a bug in qemu-img?
On Sun, 23 Nov 2008, Avi Kivity wrote: walt wrote: I do a fresh install of Windows vista on qcow2 which works perfectly. Thereafter I use that image as a backing file to make all kinds of updates to Vista, and all that works perfectly too. Then I use 'qemu-img commit' to commit all the changes I've made to Vista. The problem is that the updated base image doesn't work quite right if I try to run Vista from it -- there are minor malfunctions which indicate that the commit was incomplete or maybe just wrong. What's your sequence of commands? Are you using -snapshot? No, not using -snapshot anywhere. I'm not sure how much detail you want, but here's from the beginning: #qemu-img create -f qcow2 vista 20G #qemu-system-x86_64 -m 2048 -cdrom vistasp1.iso vista [install vista without updating and exit] #qemu-img create -f qcow2 -b vista vista.delta #qemu-system-x86_64 -m 2048 vista.delta [update vista with all the recent patches and exit] Everything above works perfectly. I can reboot vista, check for new updates, create user accounts, all the normal stuff. Now comes the trouble: #qemu-img commit vista.delta [takes 1 hour] Now, IIUC the base image vista should be entirely useable by itself, i.e. I can delete vista.delta and everyting should still work correctly? But it doesn't. For example, when I boot vista and try to look for windows updates, the updates page is almost blank and completely non-functional. There may be other problems too, but I haven't bothered to look. BTW, I've been through the same steps twice and get the same results, so I don't think it's flakey hardware. OTOH today is a new day, so I'll try it again to triple check. Any thoughts? Thanks. -- 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: [PATCH][RFC] Use writeback caching by default with qcow2
On Thu, 20 Nov 2008, Avi Kivity wrote: Thomas Mueller wrote: Right now, qcow2 isn't a reliable format regardless of the type of cache your using because metadata is not updated in the correct order. so you don't advise to use qcow2 as a VBD or what do you mean with isn't reliable? Right, qcow2 is both very slow with cache=writethrough (or off), and may corrupt itself if the host crashes at the wrong moment. or contrawise: on the other formats the metadata is updated in the correct order? raw is the only format we're sure of. With that in mind I converted my qcow2 image to raw, and I'm trying to use that as a base image to create a new raw (writeable) image: #qemu-img create -b vista.raw vista.delta Formatting 'vista.delta', fmt=raw, backing_file=vista.raw, size=20971520 kB qemu-img: Formatting or formatting option not supported for file format 'raw' Doesn't that seem like a bug? Do people just not use raw images in this way? Thanks. -- 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: qcow2 slowdown in kvm-78,79
Anthony Liguori wrote: Ryan Harper wrote: * Henrik Holst [EMAIL PROTECTED] [2008-11-18 08:42]: The bundled qemu in kvm-78 and kvm-79 slows down disk i/o with qcow2 images by an order of 10. If one got 60MB/s before, one gets around 6MB/s with 78 and 79 (measured with dd) dd command? what's your -drive parameters look like, specifically, what if type? ide, scsi, virtio? This is probably the change to cache=writethrough. I bet if you set cache=writeback then you'll see this go away. Would this affect 'qemu-img commit'? It took over an hour to commit a fresh install of Vista on a qcow2 virtual disk. (The base image expanded from 3GB to 11GB, which is a lot of committing, though.) -- 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
Commit d6469f30 breaks Vista guest
commit d6469f30cc25d3ead7305ec8ccc6a98352227e81 Author: Avi Kivity [EMAIL PROTECTED] Date: Sun May 18 11:36:42 2008 +0300 kvm: qemu: regenerate bios for ACPI _SUN method Signed-off-by: Avi Kivity [EMAIL PROTECTED] diff --git a/qemu/pc-bios/bios.bin b/qemu/pc-bios/bios.bin index 5564812..10de8d5 100644 This particular bios.bin prevents my Windows Vista from booting. The boot hangs while still in character mode, as I posted a few days ago, and using the previous bios fixes that problem. I'm going to dowload Vista SP1 and hope that the bug-fixes will cure this problem and the lack of network connection as well. (My Vistall install disk is the original RTM version.) -- 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: Latest kvm.git versus Windows Vista?
walt wrote: ... So, does anyone have Vista working on recent kvm.git? Yes. I do, but only because I forgot to load the kvm-amd kernel module. I guess that means I'm really running Vista on plain qemu, and not on kvm at all. Is that correct? -- 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
Latest kvm.git versus Windows Vista?
I see that the last post about Vista was exactly a month ago, and nothing since then. I've tried installing Vista using today's kvm.git on both 32-bit and 64-bit linux machines and failed both times, but with very different results. The common denominator between 64-bit and 32-bit linux seems to be graphics. The 64-bit Vista install works perfectly up until the final installation reboots from the virtual disk and freezes during the reboot with colorful ascii characters scattered randomly on the virtual screen -- i.e. seems like the Vista installer may have installed the wrong graphics driver(?) but I'm just guessing. The Vista install on 32-bit linux fails much earlier -- it freezes the very first time Vista's colorful graphics image of a theater curtain appears on the virtual terminal. The mouse cursor is still alive, but absolutely nothing else works at that point. Still seems graphics related to me, but again I'm just guessing. So, does anyone have Vista working on recent kvm.git? Thanks! -- 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: Preventing conflicts between kernel header versions?
walt wrote: Hi kvm team, I'm tracking Linus.git, kvm.git, and VirtualBox.svn, among other open source projects. I'm finding a conflict between kvm.git and VirtualBox.svn over the version of my linux kernel headers... Well, I just discovered the --with-patched-kernel flag, which fixes my compile problem with kvm, so I guess there is no header conflict after all. I took so long to try that flag because I didn't know what don't use external module means -- and I'm still not sure what 'external' means. External to what? Thanks! -- 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
Preventing conflicts between kernel header versions?
Hi kvm team, I'm tracking Linus.git, kvm.git, and VirtualBox.svn, among other open source projects. I'm finding a conflict between kvm.git and VirtualBox.svn over the version of my linux kernel headers. Specifically, kvm wants the files asm/kvm_para.h (and friends), but apparently looks in /usr/include/asm for those files and can't find them -- because my linux distro installs kernel headers from 2.6.26 in /usr/include/linux and /usr/include/asm. If I make /usr/include/linux and /usr/include/asm symlinks to my Linus.git repository, then kvm is happy and I'm happy -- until I try to build VirtualBox.svn, which is now broken because of those very same symlinks. Because kvm is very fussy about using exactly the correct version of the linux kernel headers, wouldn't it be reasonable to teach kvm.git to look in the right place for those headers instead of in /usr/include? I.e. /lib/modules/2.6.28-rc3/build/ for example. Is there an easier way to fix this problem? Thanks! -- 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: [PATCH 0/4] Fix vmalloc regression
Glauber Costa wrote: Nick, This is the whole set of patches I was talking about. Patch 3 is the one that in fact fixes the problem... Yep, patch 3 works for me, thanks. Only the 32-bit kernel seems to need the patch, FWIW. -- 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
