Re: 8 NIC limit
On Tue, Oct 5, 2010 at 7:48 AM, linux_...@proinbox.com wrote: Hello list: I'm working on a project that calls for the creation of a firewall in KVM. While adding a 20-interface trunk of virtio adapters to bring in a dual 10GB bond, I've discovered an 8 NIC limit in QEMU. I found the following thread in the list archives detailing a similar problem: http://kerneltrap.org/mailarchive/linux-kvm/2009/1/29/4848304 It includes a patch for the file qemu/net.h to allow 24 NICs: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm;qemu-kvm/+bug/595873/+attachment/1429544/+files/max_nics.patch In my case I want to attach 29, and have simply changed line 8 to 30 from 24. This will be the first patch I've ever had to do, and so far my internet search yields results that don't seem to apply. Would someone like to recommend a pertinent tutorial? Hi there, I commented on the original bug in Launchpad. We're willing and able to carry the patch against qemu-kvm in Ubuntu, I just asked that the reporter at least submit the patch upstream for discussion. I don't see where that has happened yet. It's a trivial patch to submit. Please note in that bug a pointer to the mailing list thread, if you start one. To your specific question, different communities have different requirements on patch submission, so you do need to consult each community. A good place to start might be the Documentation/SubmittingPatches how-to in the kernel tree: * http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/SubmittingPatches;hb=HEAD In this case, I think you're going to want to send your patch to the qemu-devel (on CC) mailing list (perhaps in addition to sending it here, to the kvm list). :-Dustin -- 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: Question on stopping KVM start at boot
On Wed, Mar 10, 2010 at 9:59 PM, sati...@pacific.net.hk wrote: $ cat /etc/init.d/qemu-kvm | grep modprobe if modprobe $module . if modprobe $module then log_end_msg 0 else log_end_msg 1 exit 1 fi ;; Where shall I add -b option? Thanks modprobe -b says respect the blacklists. See: * http://manpages.ubuntu.com/manpages/lucid/en/man8/modprobe.8.html -b --use-blacklist This option causes modprobe to apply the blacklist commands in the configuration files (if any) to module names as well. It is usually used by udev(7). So you would change the lines that say if modprobe ... to if modprobe -b ... :-Dustin -- 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: Question on stopping KVM start at boot
On Wed, Mar 10, 2010 at 3:08 AM, Bitman Zhou bitman.z...@sinobot.com.cn wrote: I need to stop KVM starting at boot. I added following 2 lines at the bottom of /etc/modprobe.d/blacklist.conf blacklist kvm blacklist kvm-amd Reboot PC It doesn't work. $ lsmod | grep kvm kvm_amd 41556 0 kvm 190648 1 kvm_amd Please what further command I have to run in order to activate the new blacklist.conf ? For Ubutnu, you can just use update-rc.d sudo update-rc.d kvm disable to disable kvm and sudo update-rc.d kvm enable to enable it again. Hi there, Unfortunately, the /etc/init.d/kvm and /etc/init.d/qemu-kvm init scripts in previous Ubuntu releases (9.10 and earlier) didn't respect the module blacklists. I have corrected this in Ubuntu 10.04 by using modprobe -b. Thus for Ubuntu 10.04 forward, you should be able to use the blacklist appropriately. For other release, you can disable the init script entirely as the other responder wrote. Or you can edit the /etc/init.d/kvm or /etc/init.d/qemu-kvm init script and add the -b option to the modprobe calls in there. -- :-Dustin -- 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: linux-aio usable?
On Mon, Mar 8, 2010 at 3:48 AM, Avi Kivity a...@redhat.com wrote: On 03/08/2010 11:48 AM, Bernhard Schmidt wrote: On Mon, Mar 08, 2010 at 11:10:29AM +0200, Avi Kivity wrote: Are there any potential pitfalls? It won't work well unless running on a block device (partition or LVM). What does work well mean in this context? Potential dataloss? No, it becomes synchronous (=extra slow). But for this to happen, the user would have had to consciously enter into the situation by creating/using a non block device, non-pre-allocated backing disk AND specify the aio=native option, correct? :-Dustin -- 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 usability
On Tue, Mar 2, 2010 at 2:21 AM, Chris Webb ch...@arachsys.com wrote: I remember about a year ago, someone asserting on the list that -usbdevice tablet was very CPU intensive even when not in use, and should be avoided if mouse support wasn't needed, e.g. on non-graphical VMs. Was that actually a significant hit, and is it still true today? I don't notice a difference from a functional standpoint. :-Dustin -- 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 usability
On Sat, Feb 27, 2010 at 4:56 AM, Ingo Molnar mi...@elte.hu wrote: Here's my experience with it: - qemu-kvm starts up with a miniature resolution by default. 640x480 - on my 1680x1050 laptop screen. It's so small that initially i even overlooked that i started it. It should multiplex pixels up to a reasonable screen size by default. - The mouse is trapped straight away by default if you click into it. That's very annoying if you actually try to integrate a guest OS into your desktop - it's not just 'another, slightly weird app' but a sticky, opinionated GUI component that you have to fight with all the time. - Once trapped it's not obvious how to untrap the mouse. The qemu window title says: QEMU: Press Ctrl-ALT to exit grab Of course once you _know_ what a 'grab' is, you'll know where to look. At minimum it should say: QEMU: Press Ctrl-ALT to exit mouse grab But to first-time users it's an annoying trap of the mouse and with no obvious place to look for help. [besides, it doesnt tell which Ctrl and which ALT to use - it's the left side. The right side Ctrl does not work.] - Graphics performance is awful even with the 640x480 miniature version. During bootup I can see it drawing single characters. This is a Core2 2.8GHz. - Sound does not work by default. I have to go dig into command-line options to see that i need to add: -soundhw all. Why isnt sound enabled by default? ..snip.. ( I could go on and on about finer details of good integration, like the difficulty of integrating host/guest files, networking, no way to quickly attach ISOs via that window, no way to activate networking, sound and no way to snapshot, no way to increase memory size except a command line option. ) ...snip... I'm not trolling you at all: is it _really_ not obvious to you that the KVM/qemu usability status quo honestly sucks, to an unbiased observer? Hi there- To a few of your comments shown above...I've noticed these two, and they've bothered me a bit. As Jan (and others) have mentioned, these are often addressed by frontends running on top of kvm (and libvirt). I look at kvm as a swissarmy knife, with lots of buttons and knobs and whistles, but you have to give it all of the right options to get it to do what you want. The graphical frontends make this easier. But running KVM from the command line, with the bare minimal options, is often a functional, but non-satisfactory impression of KVM. Maintaining the qemu-kvm package in Ubuntu, I've seen this over and over and over again, with Ubuntu users expecting a much smoother graphical experience. Why can't I get my mouse back? Why doesn't sound work? How do I make networking work? Why is the resolution so low? Etc. For these reasons (among others), we've created a little package and a python script in Ubuntu called Testdrive [1], which basically downloads an ISO (using rsync/zsync against cached images, if possible), and launches a VM with a healthy set of options. The package puts a pointy/clicky option in the Applications menu, and makes for a *very* easy way for Ubuntu users to launch a VM and try out the daily ISO builds (as well as install to the backing disk image). Once it's running, the kvm process looks something like this: kvm -m 512 -cdrom /home/kirkland/.cache/testdrive/iso/lucid-desktop-amd64.iso -drive file=/home/kirkland/.cache/testdrive/img/testdrive-disk-0086OD.img,if=virtio,index=0,boot=on -usb -usbdevice tablet -net nic,model=virtio -net user -soundhw es1370 Among these: * 512MB is a nice step up from the 128MB by default (this one scales based on your hosts memory) * virtio is used for disk and network for nice performance gains * usb device tablet greatly improves the mouse experience * sound card added * qcow2 sparse disk image * desktop is 1024 x 720 For what it's worth, you can just as easily run: testdrive -u http://download.fedoraproject.org/pub/fedora/linux/releases/12/Live/i686/Fedora-12-i686-Live.iso or any other http://, ftp://, rsync://, or file:/// accessible ISO. By no means is Testdrive supposed to be a production quality frontend for KVM (or replace any of the libvirt-based utilities like virt-manager). But I think it shows that KVM's default set of options is a little shy of what people expect for Desktop virtualization at least. For servers, lightweight defaults are perhaps more acceptable? But KVM has a number of new users by way of Ubuntu users just pointing and clicking Testdrive and launching a VM. [1] http://launchpad.net/testdrive Cheers, :-Dustin -- 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 usability
On Mon, Mar 1, 2010 at 9:14 AM, Anthony Liguori anth...@codemonkey.ws wrote: On 02/27/2010 04:56 AM, Ingo Molnar wrote: - But i'm a more advanced user so i dont need help screens, i knew that the go full screen hotkey is: LeftCtrl-LeftALT-F ... except that it is a one-way road: pressing it for a second time does not restore the window, trapping me in the guest altogether! Ctrl-ALT does not exit the trap either. I had to shut down the guest to get back my X desktop. That's a bug. The upstream QEMU bug for this is: * https://bugs.launchpad.net/qemu/+bug/483251 However, I just tried it on qemu-kvm_0.12.3 and I'm able to toggle in and out of fullscreen mode with ctrl-alt-F ad nauseum. :-Dustin -- 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 usability
On Mon, 2010-03-01 at 15:59 -0600, Anthony Liguori wrote:
On 03/01/2010 03:12 PM, Dustin Kirkland wrote:
kvm -m 512 -cdrom
/home/kirkland/.cache/testdrive/iso/lucid-desktop-amd64.iso -drive
file=/home/kirkland/.cache/testdrive/img/testdrive-disk-0086OD.img,if=virtio,index=0,boot=on
-usb -usbdevice tablet -net nic,model=virtio -net user -soundhw es1370
Among these:
* 512MB is a nice step up from the 128MB by default (this one scales
based on your hosts memory)
I'm not opposed to bumping from 128M to something else. I'd like to see
some indication though other than seems reasonable as to what the
value should be. For instance, if a Fedora 12 install doesn't work
without 256M, that's a solid argument to bump the allocation. Short
term, I'd like to see this globally configurable.
That would be very nice! I think 256MB (or even 384MB) would be a
reasonable default. Modern Ubuntu LiveCD's will work well with 256MB,
but 128MB is essentially unusable. We should just make sure that the
default is intelligently chosen based on the host's available memory
resources.
The crude logic in testdrive looks like this:
if len(MEM) == 0:
total = commands.getoutput(grep ^MemTotal /proc/meminfo | awk '{print
$2}')
if total 100:
MEM = 512
elif total 75:
MEM = 384
else:
MEM = 256
* virtio is used for disk and network for nice performance gains
The problem with virtio is that very few OSes have the drivers right
now. For networking, we can do better, and I've just written a spec for
a new feature to attempt to address this[1]. For disk, I think we're
stuck with ide as the default for a long time.
That's safe, reasonable position for upstream to make. And a sane one
for distro's to tweak depending on their intended target guest OS's.
* usb device tablet greatly improves the mouse experience
Defaulting usb to on and defaulting to a usb tablet is a reasonable
thing to do IMHO.
\o/ Definitely a better user experience.
* sound card added
This personally would annoy me but if there was wide consensus that this
was right, I'd be okay with it.
I agree that sound-on by default might be annoying to some. Speaking
for myself, if I don't want to hear guest noises, I usually don't want
to hear host noises either. In which case I mute the sound on my host
and solve both problems. But I don't feel strongly about this one.
* qcow2 sparse disk image
This is independent of qemu.
Understood. This merely seemed like the best-practice,
most-recommended, best-performing backing disk format for unwitting kvm
users launching VMs when they don't actually care what the backing
format is.
* desktop is 1024 x 720
1024x768 and this is what the default is today anyway.
Ack.
:-Dustin
signature.asc
Description: This is a digitally signed message part
Re: VMs crashing - Ubuntu 8.04, KVM84, libvirt 0.6.1
On Fri, Jan 22, 2010 at 7:12 AM, Lucas Meneghel Rodrigues l...@redhat.com wrote: On Fri, 2010-01-22 at 11:26 +, Yann Hamon wrote: Hello list, I am using Ubuntu 8.04 with the kvm84 and libvirt 0.6.1 backports. I am experiencing regular crashes of my Vms - well, more like freezes than actual crashes. This is how it looks like: http://waste.mandragor.org/kvmcpu/munin.html * The VM keeps running * The number of LOC IRQs goes down to 0, as well as the number of context switches * The number of processes gradually grows * The weird thing: some processes that were running before the crash keep running, but won't be able to fork (as you can see the munin-node continues to work) This is bothering me a lot and I have absolutely no idea how to fix it or work around it. Has this been experienced by anyone else, and/or fixed in a later version of KVM? I saw your blog post yesterday speaking about it. Unfortunately I don't have much experience with kvm under Ubuntu, so you might want to talk to Dustin, Ubuntu's maintainer of KVM. I saw some replies to your blog post suggesting you to use Dustin's PPA, have you tried to do that? I am copying Dustin on the message. As I said, I am not very knowledgeable with Ubuntu, but perhaps you should try a newer KVM build? kvm-84 is kinda... old :) A backport of a more current codebase to 8.04 could be a good idea. Thanks for the pointer, Lucas. I have worked with Yann to get a better KVM onto Ubuntu 8.04 LTS, more or less at his request. At the time, I backported the then-current kvm-84 from Ubuntu 9.04 (Jaunty) to Ubuntu 8.04 (Hardy), as a stop-gap measure, replacing the purely ancient kvm-62. Last I heard from Yann, kvm-84 (and friends) was working much better than kvm-62. Ubuntu 9.10 (Karmic) has qemu-kvm-0.11, which seems more stable than kvm-84, in my experience. And the under-development Ubuntu 10.04 LTS (Lucid) currently has qemu-kvm-0.12.2. Once Ubuntu 10.04 LTS (Lucid) ships in April (or, if I get some down time between now and then), I will attempt to backport qemu-kvm-0.12.2 to Ubuntu 8.04 (Hardy). There's more than a few complications with doing this backport, and it takes considerable effort to do so, as there are several pieces that must be handled, and thoroughly tested, including at least: a) the modern kvm kernel module, and getting it building under DKMS b) the modern qemu-kvm userspace, getting it building against the older toolchain c) the modern libvirt library, getting it building against the older toolchain d) testing the interoperability of all of the above My efforts are currently 110% committed against developing Ubuntu 10.04 LTS (Lucid), and the virtualization stack there. Yann, and anyone wanting a backported virtualization stack against Ubuntu 8.04 LTS should follow the procedures at: * https://help.ubuntu.com/community/UbuntuBackports and ideally someone from the Ubuntu community with backport experience can help get a new version building and tested. If there's someone volunteering to help with that work, I'll gladly mentor them and guide the process, sign, and upload packages to the Ubuntu repositories on their behalf. Cheers, :-Dustin -- 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: VMs crashing - Ubuntu 8.04, KVM84, libvirt 0.6.1
On Wed, 2010-01-27 at 22:11 +, Yann Hamon wrote: Thanks for the pointer, Lucas. I have worked with Yann to get a better KVM onto Ubuntu 8.04 LTS, more or less at his request. At the time, I backported the then-current kvm-84 from Ubuntu 9.04 (Jaunty) to Ubuntu 8.04 (Hardy), as a stop-gap measure, replacing the purely ancient kvm-62. Last I heard from Yann, kvm-84 (and friends) was working much better than kvm-62. Hello Dustin, thanks for replying here, and thank you again for the backports. The backports indeed fixes major problems that I was having with kvm62 - however I am experiencing regular crashes and haven't been able to figure out why, til now. This didn't occured during my testing phase, and even now occur fairly rarely (one same VM would crash every month or so) - but becomes an issue as you get more vms. Right, per our former conversations, kvm-84 seemed significantly better. I'm sorry that it's still not totally stable. Ubuntu 9.10 (Karmic) has qemu-kvm-0.11, which seems more stable than kvm-84, in my experience. And the under-development Ubuntu 10.04 LTS (Lucid) currently has qemu-kvm-0.12.2. Once Ubuntu 10.04 LTS (Lucid) ships in April (or, if I get some down time between now and then), I will attempt to backport qemu-kvm-0.12.2 to Ubuntu 8.04 (Hardy). I think it's more me who assumed I would have a more stable KVM if I sticked to LTS - KVM being relatively new, I might have been better off upgrading every 6 months. Am readying my hosts for 10.4 as I speak... Right, so KVM in particular is a bit of a special case, in that it's evolving so much faster than traditional server projects (take something like postfix, bind, or ssh). For most server workloads, I would generally point you at an Ubuntu LTS for optimum stability. Unfortunately, KVM was barely 1 year old when Ubuntu 8.04 released in April of 2008, and has stabilized tremendously in the last 2 years. Specifically if your key workload is KVM virtual machine hosting, I would actually recommending upgrading through the non-LTS Ubuntu releases. All that said, I think the KVM (linux-2.6.32 + qemu-kvm-0.12.2) story on Ubuntu 10.04 LTS is going to be very different than KVM (linux-2.6.24 + kvm-62) story was on Ubuntu 8.04 LTS. Stability is absolutely Ubuntu's focus for the 10.04 release. And I gather from the upstream KVM and QEMU developers that releases of KVM in linux 2.6.32 and qemu-kvm 0.12.2 are far more stable as well. There's more than a few complications with doing this backport, and it takes considerable effort to do so, as there are several pieces that must be handled, and thoroughly tested, including at least: a) the modern kvm kernel module, and getting it building under DKMS b) the modern qemu-kvm userspace, getting it building against the older toolchain c) the modern libvirt library, getting it building against the older toolchain d) testing the interoperability of all of the above Indeed. Are you aware of any other production deployment using 8.04 experiencing issues? If not, maybe it's just not worth it. There were definitely other people who were able to confirm some of the issues you raised with Hardy's kvm-62. All of those (that I know of) were pleased with the backported kvm-84, for those particular issues, at least. My efforts are currently 110% committed against developing Ubuntu 10.04 LTS (Lucid), and the virtualization stack there. Yann, and anyone wanting a backported virtualization stack against Ubuntu 8.04 LTS should follow the procedures at: * https://help.ubuntu.com/community/UbuntuBackports and ideally someone from the Ubuntu community with backport experience can help get a new version building and tested. If there's someone volunteering to help with that work, I'll gladly mentor them and guide the process, sign, and upload packages to the Ubuntu repositories on their behalf. Oh my KVM hosts don't do much more than KVM, so I'd be fine with any version of Ubuntu, really. Will probably move my dev vms to lucid alpha, and test for a few months - and migrate everything to there after release. I think this would be a very wise approach! Move one or two physical systems over to Lucid Alpha3 when it releases next week. File bugs you find against Lucid Alpha3 and we'll work through those issues, and upload fixes with great fervor and a much quicker turn-around. From there I might do the 6 months upgrade. Just thought that if the bug I am having was known and fixed I might get a quick workaround which would have helped me wait :) Once Ubuntu 10.04 LTS releases, if all of your blocking bugs are fixed, then I'd stick with that until the next LTS (12.04-ish). Basically, I'd only upgrade if there's something in particular that I know is broken in one release, and is fixed in the next. :-Dustin signature.asc Description: This is a digitally signed message part
Re: [ANNOUNCE] qemu-kvm-0.12.2
On Thu, Jan 21, 2010 at 11:43 AM, Michael Tokarev m...@tls.msk.ru wrote: Marcelo Tosatti wrote: qemu-kvm-0.12.2 is now available. This release is based on the upstream qemu 0.12.2, plus kvm-specific enhancements. Please see the original qemu 0.12.2 release announcement for details. Thank you Avi, Marcelo and all others, for the new release. On my side, I've updated the Debian packages on the usual place, http://www.corpit.ru/debian/tls/kvm/ , for both i386 and amd64. I have uploaded the qemu-kvm_0.12.2-0ubuntu1 Ubuntu package to the Lucid (development) archive. It's building now, should be published within the hour. :-Dustin -- 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 developer call minutes (Jan 19)
cpu-uname.h
+
+/* return highest utsname machine name for emulated instruction set
+ *
+ * NB: the default emulated CPU (any) might not match any existing CPU, e.g.
+ * on ARM it has all features turned on, so there is no perfect arch string to
+ * return here */
+const char *cpu_to_uname_machine(void *cpu_env)
+{
+#ifdef TARGET_ARM
+/* utsname machine name on linux arm is CPU arch name + endianness, e.g.
+ * armv7l; to get a list of CPU arch names from the linux source, use:
+ * grep arch_name: -A1 linux/arch/arm/mm/proc-*.S
+ * see arch/arm/kernel/setup.c: setup_processor()
+ *
+ * to test by CPU id, compare cpu_env-cp15.c0_cpuid to ARM_CPUID_*
+ * defines and to test by CPU feature, use arm_feature(cpu_env,
+ * ARM_FEATURE_*) */
+
+/* in theory, endianness is configurable on some ARM CPUs, but this isn't
+ * used in user mode emulation */
+#ifdef TARGET_WORDS_BIGENDIAN
+#define utsname_suffix b
+#else
+#define utsname_suffix l
+#endif
+if (arm_feature(cpu_env, ARM_FEATURE_V7))
+return armv7 utsname_suffix;
+if (arm_feature(cpu_env, ARM_FEATURE_V6))
+return armv6 utsname_suffix;
+/* earliest emulated CPU is ARMv5TE; qemu can emulate the 1026, but not its
+ * Jazelle support */
+return armv5te utsname_suffix;
+#elif defined(TARGET_X86_64)
+return x86-64;
+#elif defined(TARGET_I386)
+/* see arch/x86/kernel/cpu/bugs.c: check_bugs(), 386, 486, 586, 686 */
+uint32_t cpuid_version = ((CPUX86State *)cpu_env)-cpuid_version;
+int family = ((cpuid_version 8) 0x0f) + ((cpuid_version 20) 0xff);
+if (family == 4)
+return i486;
+if (family == 5)
+return i586;
+return i686;
+#else
+/* default is #define-d in each arch/ subdir */
+return UNAME_MACHINE;
+#endif
+}
diff --git a/linux-user/cpu-uname.h b/linux-user/cpu-uname.h
new file mode 100644
index 000..32492de
--- /dev/null
+++ b/linux-user/cpu-uname.h
@@ -0,0 +1 @@
+const char *cpu_to_uname_machine(void *cpu_env);
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index f2dd39e..9fb493f 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -82,6 +82,7 @@
#include linux/fb.h
#include linux/vt.h
#include linux_loop.h
+#include cpu-uname.h
#include qemu.h
#include qemu-common.h
@@ -5739,7 +5740,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
if (!is_error(ret)) {
/* Overrite the native machine name with whatever is being
emulated. */
-strcpy (buf-machine, UNAME_MACHINE);
+strcpy (buf-machine, cpu_to_uname_machine(cpu_env));
/* Allow the user to override the reported release. */
if (qemu_uname_release *qemu_uname_release)
strcpy (buf-release, qemu_uname_release);
--
1.6.5
qemu-img: improve error reporting
Use strerror to provide a better error message when qemu-img fails.
https://bugs.edge.launchpad.net/ubuntu/+source/qemu-kvm/+bug/418112
Signed-off-by: Dustin Kirkland kirkl...@canonical.com
diff -uprN qemu-kvm-0.11.0~rc2/qemu-img.c qemu-kvm-0.11.0~rc2.new/qemu-img.c
--- qemu-kvm-0.11.0~rc2/qemu-img.c 2009-08-30 04:10:59.0 -0500
+++ qemu-kvm-0.11.0~rc2.new/qemu-img.c 2009-09-10 22:30:32.572211443 -0500
@@ -368,7 +368,7 @@ static int img_create(int argc, char **a
} else if (ret == -EFBIG) {
error(The image size is too large for file format '%s', fmt);
} else {
-error(Error while formatting);
+error(Error while formatting (%s), strerror(-ret));
}
}
return 0;
Re: [ANNOUNCE] qemu-kvm-0.12.0-rc2 released
On Sun, Dec 20, 2009 at 10:25 AM, Avi Kivity a...@redhat.com wrote: On 12/15/2009 05:21 PM, Dustin Kirkland wrote: - fetch the submodules and include them in the tarball ... I think this option would help keep us all on the same page. But I could live with pointers to the submodules, since packaging a new release only happens a couple of times per year. Due to time constraints I went for the simpler option of adding a generated EXTERNAL_DEPENDENCIES file. Patches for including the source are welcome. Fair enough. It's straightforward by hand, and I only really package twice a year. What about the qemu-system-arm build break I also mentioned? That's currently blocking my packaging. Thanks, :-Dustin -- 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: [ANNOUNCE] qemu-kvm-0.12.0-rc2 released
On Tue, 2009-12-15 at 11:10 +0200, Avi Kivity wrote: Well, binaries are shipped, but I guess you'd like to build from source. Right, sorry I was ambiguous. We have several options: ... - fetch the submodules and include them in the tarball ... I think this option would help keep us all on the same page. But I could live with pointers to the submodules, since packaging a new release only happens a couple of times per year. :-Dustin signature.asc Description: This is a digitally signed message part
Re: [ANNOUNCE] qemu-kvm-0.12.0-rc2 released
On Mon, Dec 14, 2009 at 12:33 PM, Avi Kivity a...@redhat.com wrote: qemu-kvm-0.12.0-rc2 is now available. This release is is based on the upstream qemu 0.12.0-rc2, plus kvm-specific enhancements. Please see the original qemu 0.12.0-rc2 release announcement for details. This release can be used with the kvm kernel modules provided by your distribution kernel, or by the modules in the kvm-kmod package, such as kvm-kmod-2.6.32. Please give test this release out so we can enjoy a stable 0.12.0 final release. Hi Avi/Anthony- I'm working on the packaging updates for Ubuntu Lucid, and I'm having trouble with the BIOS bits of qemu-kvm. It seems that a fair amount of the BIOS submodules are missing. The roms/ tree is basically empty. I see some of the necessary bits in pc-bios/ and in kvm/vgabios/, but not enough here to build a usable qemu-kvm-0.12.0~rc2 package yet. :-Dustin -- 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: Hot-adding disk on VM
On Sat, Nov 7, 2009 at 7:01 PM, Daniel Bareiro daniel-lis...@gmx.net wrote: According to I see in Launchpad, there is a fix released for Qemu and qemu-kvm (Ubuntu). It's fix committed in QEMU, and Fix Released in Ubuntu's qemu-kvm. We in Ubuntu have released version of qemu-kvm-0.11.0 that includes an extra patch from Anthony, which he posted on the mailing list, and committed to QEMU's git tree. He hasn't officially released an upstream QEMU with the fix yet, though. I'm using KVM-88 compiled from the source code obtained of the KVM official site. How I could apply these fix? There is some KVM version that includes these corrections in the official site? Not that I know of, yet. You can pull the patch [1] we're carrying in Ubuntu, and apply it to qemu-kvm-0.11.0 [2] from the kvm website, if you like. [1] http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/karmic/qemu-kvm/karmic/annotate/head%3A/debian/patches/11_fix_virtio-blk_hot_add_after_remove.patch [2] http://sourceforge.net/projects/kvm/files/ :-Dustin -- 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: [PATCH] whitelist host virtio networking features [was Re: qemu-kvm-0.11 regression, crashes on older ...]
On Mon, Nov 2, 2009 at 8:38 AM, Mark McLoughlin mar...@redhat.com wrote: On Fri, 2009-10-30 at 16:15 -0500, Dustin Kirkland wrote: Canonical's Ubuntu Security Team will be filing a CVE on this issue, since there is a bit of an attack vector here, and since qemu-kvm-0.11.0 is generally available as an official release (and now part of Ubuntu 9.10). Guests running linux = 2.6.25 virtio-net (e.g Ubuntu 8.04 hardy) on top of qemu-kvm-0.11.0 can be remotely crashed by a non-privileged network user flooding an open port on the guest. The crash happens in a manner that abruptly terminates the guest's execution (ie, without shutting down cleanly). This may affect the guest filesystem's general happiness. IMHO, the CVE should be against the 2.6.25 virtio drivers - the bug is in the guest and the issue we're discussing here is just a hacky workaround for the guest bug. Kees/Jamie/Marc- I think Mark has a good point. This bug has two parts. Ultimately, it's triggered by a buggy virtio-net implementation in the Ubuntu 8.04 kernel (as well as any others using the circa 2.6.25 virtio net code). The CVE should probably mention (or focus on) this too. The qemu-kvm patch is still a good thing to do, as it shouldn't just exit and terminate the VM, so that's needed as well. :-Dustin -- 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-devel] Re: [PATCH] whitelist host virtio networking features [was Re: qemu-kvm-0.11 regression, crashes on older ...]
On Mon, 2009-11-02 at 12:55 -0600, Anthony Liguori wrote: They can exit qemu via an ACPI shutdown. I don't see the difference. An ACPI shutdown is triggered by an authenticated user inside of the guest. The present exit is triggered by any other anonymous user on the network, with the ability to send a lot of packets very quickly to the VM guest. The guest isn't able to handle this properly (and rightly that guest's kernel should be fixed). But I do see a difference. :-Dustin signature.asc Description: This is a digitally signed message part
Ubuntu Patches [was Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network]
On Thu, Oct 29, 2009 at 6:22 PM, Scott Tsai scottt...@gmail.com wrote: What's the easiest way to see the patches to qemu that Canonical carries for the different Ubuntu releases? (I think http://patches.ubuntu.com/ only diffs against Debian for the last stable Ubuntu release?) Correct. That site is sort of intended to show where Ubuntu's packages differ from Debian. I've spoken with the person behind that site (Jorge Castro) and he offered to see what could be done to make it more useful to upstream projects. You can direct your suggestions to him. However, all of our packages are now maintained in Bazaar in Launchpad. You can (a) checkout the source of the package using bzr, and going to the debian/patches directory. Or you can (b) browse the source code over http using Loggerhead (sort of like gitweb for bzr). (a) bzr checkout lp:ubuntu/qemu-kvm/karmic (b) https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/karmic/qemu-kvm/karmic/files/head%3A/debian/patches/ Very soon, you'll probably be more interested in lucid than karmic, very soon. In which case, s/karmic/lucid/ against those URLs. Also, is there a way for an outside developer to get email notifications when a patch is added to Ubuntu's qemu package? Sort of... You can subscribe for email notifications to changes to any given package in Launchpad. Assuming you have a Launchpad account, you can log in and go to: * https://code.launchpad.net/~ubuntu-branches/ubuntu/karmic/qemu-kvm/karmic To the right, there's a link to Subscribe yourself. You'll get email to changes to that package in the given release (karmic, in this case, so modify the url accordingly). You might have to ignore some packaging changes, as some changes don't necessarily touch the core qemu-kvm code, for instance. :-Dustin -- 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: [PATCH] whitelist host virtio networking features [was Re: qemu-kvm-0.11 regression, crashes on older ...]
On Thu, Oct 29, 2009 at 10:34 AM, Dustin Kirkland kirkl...@canonical.com wrote: whitelist host virtio networking features This patch is a followup to 8eca6b1bc770982595db2f7207c65051572436cb, fixing crashes when guests with 2.6.25 virtio drivers have saturated virtio network connections. https://bugs.edge.launchpad.net/ubuntu/+source/qemu-kvm/+bug/458521 That patch should have been whitelisting *_HOST_* rather than the the *_GUEST_* features. I tested this by running an Ubuntu 8.04 Hardy guest (2.6.24 kernel + 2.6.25-virtio driver). I saturated both the incoming, and outgoing network connection with nc, seeing sustained 6MB/s up and 6MB/s down bitrates for ~20 minutes. Previously, this crashed immediately. Now, the guest does not crash and maintains network connectivity throughout the test. snip FYI... Canonical's Ubuntu Security Team will be filing a CVE on this issue, since there is a bit of an attack vector here, and since qemu-kvm-0.11.0 is generally available as an official release (and now part of Ubuntu 9.10). Guests running linux = 2.6.25 virtio-net (e.g Ubuntu 8.04 hardy) on top of qemu-kvm-0.11.0 can be remotely crashed by a non-privileged network user flooding an open port on the guest. The crash happens in a manner that abruptly terminates the guest's execution (ie, without shutting down cleanly). This may affect the guest filesystem's general happiness. :-Dustin -- 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-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network
On Thu, 2009-10-29 at 14:25 +, Mark McLoughlin wrote: On Thu, 2009-10-29 at 09:11 -0500, Anthony Liguori wrote: Mark McLoughlin wrote: tap_set_offload(csum: 1, tso4: 1, tso6: 1, ecn: 1) being called and get an mtu of 1500 on virbr0 using his birdge.sh script. virtio_net_receive2 was trying to transfer a 1534 byte packet (1524 'size' + 10 'virtio_net_hdr') and the guest only had 1524 bytes of space in its input descriptors. Okay, that sounds like a bug in Dustin's version of the guest virtio-net driver - if it is only supplying 1524 byte buffers, it should not be saying it supports the VIRTIO_NET_F_GUEST_TSO4 feature See: commit 8eca6b1bc770982595db2f7207c65051572436cb Author: aliguori aligu...@c046a42c-6fe2-441c-8c8c-71466251a162 Date: Sun Apr 5 17:40:08 2009 + Fix oops on 2.6.25 guest (Rusty Russell) I believe this is behind the following: https://bugs.edge.launchpad.net/ubuntu/jaunty/+source/linux/+bug/331128 virtio_pci in 2.6.25 didn't do feature negotiation correctly: it acked every bit. Fortunately, we can detect this. Signed-off-by: Rusty Russell ru...@rustcorp.com.au Signed-off-by: Anthony Liguori aligu...@us.ibm.com It looks like Rusty's fix wasn't enough. If I change virtio-net to only advertise F_MAC, we don't run into this problem. If it's not acking VBAD_FEATURE, then it doesn't sound like the same issue It's also not acking e.g. MRG_RXBUF, which suggests that it is selectively acking features, and choosing to ack TSO4 A quick look through the guest driver code should clear up the confusion. Dustion, got a pointer? Hi Mark, I'm currently testing Scott's patch above. In the mean time, Hardy's kernel is in git here: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=summary Thanks, :-Dustin signature.asc Description: This is a digitally signed message part
Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network
On Thu, 2009-10-29 at 20:00 +0800, Scott Tsai wrote: Excerpts from Mark McLoughlin's message of Thu Oct 29 17:16:43 +0800 2009: Assuming this is something like the virtio-net in 2.6.26, there was no receivable buffers support so (as Scott points out) it must be that we've read a packet from the tap device which is 1514 bytes (or 1524 bytes with IFF_VNET_HDR) but the guest has not supplied buffers which are large enough to take it One thing to check is that the tap device is being initialized by qemu-kvm using TUNSETOFFLOAD with either zero or TUN_F_CSUM - i.e. GSO should not be enabled, because the guest cannot handle large GSO packets Another possibility is that the MTU on the bridge in the host is too large and that's what's causing the large packets to be sent Using Dustin's image, I see: virtio_net_set_features(features: 0x0930) tap_set_offload(csum: 1, tso4: 1, tso6: 1, ecn: 1) being called and get an mtu of 1500 on virbr0 using his birdge.sh script. virtio_net_receive2 was trying to transfer a 1534 byte packet (1524 'size' + 10 'virtio_net_hdr') and the guest only had 1524 bytes of space in its input descriptors. BTW, I can also reproduce this running Dustin's image inside Fedora 11's qemu-0.10.6-9.fc11.x86_64. The patch I posted earlier actually only applies to the 0.10 branch, here's a patch that compiles for 0.11: Hi Scott, Thanks for this. Testing this, kvm doesn't crash. And the guest has working network connectivity, until I saturate the network connection with nc. At that point, the guest loses network connectivity all together. So the fix is not quite ideal, yet. :-Dustin signature.asc Description: This is a digitally signed message part
Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network
On Thu, 2009-10-29 at 09:16 +, Mark McLoughlin wrote:
Hi Dustin,
On Wed, 2009-10-28 at 14:22 -0500, Dustin Kirkland wrote:
I believe that we have identified a regression in qemu-kvm-0.11.0.
Regression versus which previous version of qemu-kvm?
Okay, sorry for the ambiguity. I actually had to clarify this for
myself. The regression is as compared to the kvm-84 package that the
previous version of Ubuntu (9.04 Jaunty) carried.
In this package, we carried the attached patch from Anthony Liguori.
I had incorrectly assumed that this patch made it into the upstream
tree. As Anthony stated in his earlier email, a different
implementation of the fix from Rusty was committed instead. The fix as
committed doesn't quite solve the problem as we're experiencing it.
:-Dustin
Work around broken virtio drivers in 2.6.26
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
diff --git a/qemu/hw/virtio-net.c b/qemu/hw/virtio-net.c
index 9bce3a0..5b615f9 100644
--- a/qemu/hw/virtio-net.c
+++ b/qemu/hw/virtio-net.c
@@ -120,6 +120,9 @@ static uint32_t virtio_net_get_features(VirtIODevice *vdev)
if (tap_has_vnet_hdr(host)) {
tap_using_vnet_hdr(host, 1);
+#if 0
+/* Stop advertising advanced features until we work around the fact
+ * that this is totally broken in 2.6.26 kernels */
features |= (1 VIRTIO_NET_F_CSUM);
features |= (1 VIRTIO_NET_F_GUEST_CSUM);
features |= (1 VIRTIO_NET_F_GUEST_TSO4);
@@ -130,6 +133,7 @@ static uint32_t virtio_net_get_features(VirtIODevice *vdev)
features |= (1 VIRTIO_NET_F_HOST_ECN);
features |= (1 VIRTIO_NET_F_MRG_RXBUF);
/* Kernel can't actually handle UFO in software currently. */
+#endif
}
#endif
@@ -374,8 +378,14 @@ static int receive_header(VirtIONet *n, struct iovec *iov, int iovcnt,
struct virtio_net_hdr *hdr = iov[0].iov_base;
int offset = 0;
+#if 0
hdr-flags = 0;
hdr-gso_type = VIRTIO_NET_HDR_GSO_NONE;
+#else
+/* we need to clear out the whole header, including any garbage that may be
+ */
+memset(hdr, 0, sizeof(*hdr));
+#endif
#ifdef TAP_VNET_HDR
if (tap_has_vnet_hdr(n-vc-vlan-first_client)) {
signature.asc
Description: This is a digitally signed message part
Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network
On Thu, 2009-10-29 at 09:34 -0500, Dustin Kirkland wrote: In the mean time, Hardy's kernel is in git here: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=summary I'll save you a few clicks... http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=blob;f=drivers/net/virtio_net.c;h=d1a200ff5fd266c05e9a876e5e4e550737f77d84;hb=HEAD :-dustin signature.asc Description: This is a digitally signed message part
Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network
On Thu, 2009-10-29 at 14:48 +, Mark McLoughlin wrote: Ah, it all makes sense now. I was getting confused between HOST_* and GUEST_* this should have been: features |= (1 VIRTIO_NET_F_MAC); features |= (1 VIRTIO_NET_F_HOST_CSUM); features |= (1 VIRTIO_NET_F_HOST_TSO4); features |= (1 VIRTIO_NET_F_HOST_TSO6); features |= (1 VIRTIO_NET_F_HOST_ECN); Could you try that Dustin? Hmm, not sure I'm doing this correctly... I tried changing the following, but looks like I might also have to define these as well, since: /tmp/qemu-kvm/qemu-kvm/hw/virtio-net.c:167: error: ‘VIRTIO_NET_F_HOST_CSUM’ undeclared (first use in this function) diff --git a/hw/virtio-net.c b/hw/virtio-net.c index ce8e6cb..6582e69 100644 --- a/hw/virtio-net.c +++ b/hw/virtio-net.c @@ -164,10 +164,10 @@ static uint32_t virtio_net_bad_features(VirtIODevice *vdev) /* Linux kernel 2.6.25. It understood MAC (as everyone must), * but also these: */ features |= (1 VIRTIO_NET_F_MAC); -features |= (1 VIRTIO_NET_F_GUEST_CSUM); -features |= (1 VIRTIO_NET_F_GUEST_TSO4); -features |= (1 VIRTIO_NET_F_GUEST_TSO6); -features |= (1 VIRTIO_NET_F_GUEST_ECN); +features |= (1 VIRTIO_NET_F_HOST_CSUM); +features |= (1 VIRTIO_NET_F_HOST_TSO4); +features |= (1 VIRTIO_NET_F_HOST_TSO6); +features |= (1 VIRTIO_NET_F_HOST_ECN); return features virtio_net_get_features(vdev); } signature.asc Description: This is a digitally signed message part
Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network
On Thu, 2009-10-29 at 15:01 +, Mark McLoughlin wrote: Sorry, should be VIRTIO_NET_F_CSUM ... the rest is correct Brilliant! Works like a champ. I'll send a patch in a subsequent email. Would you add a signed-off-by (or whatever), Mark? :-Dustin signature.asc Description: This is a digitally signed message part
[PATCH] whitelist host virtio networking features [was Re: qemu-kvm-0.11 regression, crashes on older ...]
whitelist host virtio networking features This patch is a followup to 8eca6b1bc770982595db2f7207c65051572436cb, fixing crashes when guests with 2.6.25 virtio drivers have saturated virtio network connections. https://bugs.edge.launchpad.net/ubuntu/+source/qemu-kvm/+bug/458521 That patch should have been whitelisting *_HOST_* rather than the the *_GUEST_* features. I tested this by running an Ubuntu 8.04 Hardy guest (2.6.24 kernel + 2.6.25-virtio driver). I saturated both the incoming, and outgoing network connection with nc, seeing sustained 6MB/s up and 6MB/s down bitrates for ~20 minutes. Previously, this crashed immediately. Now, the guest does not crash and maintains network connectivity throughout the test. Signed-off-by: Dustin Kirkland kirkl...@canonical.com Signed-off-by: Mark McLoughlin mar...@redhat.com Tested-by: Dustin Kirkland kirkl...@canonical.com diff --git a/hw/virtio-net.c b/hw/virtio-net.c index ce8e6cb..27834fa 100644 --- a/hw/virtio-net.c +++ b/hw/virtio-net.c @@ -164,10 +164,10 @@ static uint32_t virtio_net_bad_features(VirtIODevice *vdev) /* Linux kernel 2.6.25. It understood MAC (as everyone must), * but also these: */ features |= (1 VIRTIO_NET_F_MAC); -features |= (1 VIRTIO_NET_F_GUEST_CSUM); -features |= (1 VIRTIO_NET_F_GUEST_TSO4); -features |= (1 VIRTIO_NET_F_GUEST_TSO6); -features |= (1 VIRTIO_NET_F_GUEST_ECN); +features |= (1 VIRTIO_NET_F_CSUM); +features |= (1 VIRTIO_NET_F_HOST_TSO4); +features |= (1 VIRTIO_NET_F_HOST_TSO6); +features |= (1 VIRTIO_NET_F_HOST_ECN); return features virtio_net_get_features(vdev); } signature.asc Description: This is a digitally signed message part
qemu-kvm-0.11 regression, crashes on older guests with virtio network
I believe that we have identified a regression in qemu-kvm-0.11.0. The kvm process crashes for older guests with virtio networking, when the guest's incoming network connection is saturated. The subject guest is Ubuntu 8.04 Hardy, 2.6.24 kernel with virtio backports. For your convenience, I have uploaded a stock, ~260MB Ubuntu 8.04 disk image (user/pw = ubuntu) that I'm using to reproduce the problem at: * http://rookery.canonical.com/~kirkland/hardy.img.bz2 The command line is: * sudo /usr/bin/kvm -m 512 -net nic,model=virtio -net tap,script=/home/kirkland/bin/bridge.sh -drive file=hardy.img,if=virtio,index=0,boot=on The bridge script is: * http://rookery.canonical.com/~kirkland/bridge.sh I'm saturating the guest's incoming network connection, with: u...@guest$ nc -lp 1234 /dev/null and u...@host$ cat /dev/urandom | nc -w 3 guest_ip 1234 In less than a second of sending, the vm crashes with: virtio-net truncating packet I have strace logs, if that's helpful. I have not reproduced the problem: a) by saturating the guest's outgoing network b) with newer guests ( = 2.6.27 ) c) on kvm-84 on the host We're tracking this issue at: * https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/458521 I'll gladly review and test patches, or take pointers on where I might look to solve this issue. -- :-Dustin -- 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-0.11 regression, crashes on older guests with virtio network
On Wed, Oct 28, 2009 at 2:22 PM, Dustin Kirkland kirkl...@canonical.com wrote: I have not reproduced the problem: a) by saturating the guest's outgoing network b) with newer guests ( = 2.6.27 ) c) on kvm-84 on the host d) or by using e1000, or rtl8139 NIC models. :-Dustin -- 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-devel] [STABLE PATCH] hotplug: fix scsi hotplug.
On Wed, Oct 14, 2009 at 8:30 AM, Gerd Hoffmann kra...@redhat.com wrote:
Well, partly just papering over the issues. But without proper scsi bus
infrastructure we hardly can do better. Changes:
* Avoid auto-attach by setting the bus number to -1.
* Ignore the unit value calculated by drive_init().
* Explicitly attach the devices to the adapter.
* Add sanity checks. Don't allow attaching scsi drives to your
network device.
* Kill the bus+unit printing. The values are bogus, and we can't
easily figure the correct ones. I doubt this ever worked correctly
with multiple scsi adapters present in the system.
Should come more close to the expected behavior now ...
Oh, and pc-bios/bios.bin needs a update too, otherwise pci hotplug
doesn't work at all.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/pci-hotplug.c | 24 +++-
pc-bios/bios.bin | Bin 131072 - 131072 bytes
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/hw/pci-hotplug.c b/hw/pci-hotplug.c
index d0f2911..8bedea2 100644
--- a/hw/pci-hotplug.c
+++ b/hw/pci-hotplug.c
@@ -52,9 +52,10 @@ void drive_hot_add(Monitor *mon, const char *pci_addr,
const char *opts)
{
int dom, pci_bus;
unsigned slot;
- int drive_idx, type, bus;
+ int drive_idx, type;
int success = 0;
PCIDevice *dev;
+ char buf[128];
if (pci_read_devaddr(mon, pci_addr, dom, pci_bus, slot)) {
return;
@@ -74,11 +75,19 @@ void drive_hot_add(Monitor *mon, const char *pci_addr,
const char *opts)
return;
}
type = drives_table[drive_idx].type;
- bus = drive_get_max_bus (type);
switch (type) {
case IF_SCSI:
+ if (!dev-qdev.info || strcmp(dev-qdev.info-name, lsi53c895a) !=
0) {
+ monitor_printf(mon, Device is not a scsi adapter\n);
+ break;
+ }
success = 1;
+ drives_table[drive_idx].bus = -1;
+ drives_table[drive_idx].unit = -1;
+ if (get_param_value(buf, sizeof(buf), unit, opts)) {
+ drives_table[drive_idx].unit = atoi(buf);
+ }
lsi_scsi_attach(dev-qdev, drives_table[drive_idx].bdrv,
drives_table[drive_idx].unit);
break;
@@ -87,9 +96,7 @@ void drive_hot_add(Monitor *mon, const char *pci_addr,
const char *opts)
}
if (success)
- monitor_printf(mon, OK bus %d, unit %d\n,
- drives_table[drive_idx].bus,
- drives_table[drive_idx].unit);
+ monitor_printf(mon, OK\n);
return;
}
@@ -130,7 +137,14 @@ static PCIDevice *qemu_pci_hot_add_storage(Monitor *mon,
switch (type) {
case IF_SCSI:
+ drives_table[drive_idx].bus = -1;
+ drives_table[drive_idx].unit = -1;
+ if (get_param_value(buf, sizeof(buf), unit, opts)) {
+ drives_table[drive_idx].unit = atoi(buf);
+ }
dev = pci_create(lsi53c895a, devaddr);
+ lsi_scsi_attach(dev-qdev, drives_table[drive_idx].bdrv,
+ drives_table[drive_idx].unit);
break;
case IF_VIRTIO:
dev = pci_create(virtio-blk-pci, devaddr);
Thanks, Gerd.
I applied this patch against qemu-kvm-0.11.0 stable, built, and tested
it. I can verify that it fixes the scsi hot-add issues I was seeing.
I am now able to add/remove/add/remove/add/remove a scsi disk to a
running instance without segfaulting qemu.
Note that on remove, I do get a stack track in the guest's kernel
(2.6.31), though the remove does succeed, and the disk disappears.
Also note that I did not replace the bios.bin, as it appears to me
that the qemu-kvm-0.11 bios.bin is working properly.
Tested-by: Dustin Kirkland kirkl...@canonical.com
--
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: sync guest calls made async on host - SQLite performance
On Tue, Oct 13, 2009 at 9:09 PM, Matthew Tippett tippe...@gmail.com wrote: I believe that I have removed the benchmark from discussion, we are now looking at semantics of small writes followed by ... And quoting from Dustin === I have tried this, exactly as you have described. The tests took: * 1162.08033204 seconds on native hardware * 2306.68306303 seconds in a kvm using if=scsi disk * 405.382308006 seconds in a kvm using if=virtio Hang on now... My timings are from running the Phoronix test *as you described*. I have not looked at what magic is happening inside of this Phoronix test. I am most certainly *not* speaking as to the quality or legitimacy of the test. :-Dustin -- 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: Hot-adding disk on VM
On Sun, Oct 11, 2009 at 4:51 PM, Daniel Bareiro daniel-lis...@gmx.net wrote: Hi, all! On Saturday, 22 August 2009 10:59:47 -0300, Daniel Bareiro wrote: According to I see in this document [1], is necessary that is loaded two modules in the guest: acpiphp and pci_hotplug. The pci_hotplug module is loaded. Nevertheless, in spite of existing the acpiphp module, cannot be loaded: chandra:~# lsmod|grep pci_hotplug pci_hotplug 23460 0 chandra:~# modprobe acpiphp FATAL: Error inserting acpiphp (/lib/modules/2.6.26-2-686/kernel/drivers/pci/hotplug/acpiphp.ko): No such device chandra:~# locate acpiphp | grep 686 /lib/modules/2.6.26-2-686/kernel/drivers/pci/hotplug/acpiphp.ko /lib/modules/2.6.26-2-686/kernel/drivers/pci/hotplug/acpiphp_ibm.ko Which could be being the problem? I was doing other tests this time with Linux 2.6.31.2 compiled by myself from the sources of kernel.org. This time with loading the acpiphp module, the pci_hotplug module was loaded automatically without I get some type of error message. central:~# lsmod | grep acpiphp central:~# central:~# modprobe acpiphp central:~# central:~# lsmod | grep acpiphp acpiphp 22140 0 pci_hotplug 29024 1 acpiphp Then, I tried to add a disk of the following way in host: (qemu) pci_add auto storage file=/dev/vm/central-test,if=virtio OK domain 0, bus 0, slot 5, function 0 In the guest: Oct 11 18:09:01 central kernel: [ 833.403875] pci :00:02.0: BAR 6: bogus alignment [0x0-0x0] flags 0x2 Oct 11 18:09:01 central kernel: [ 833.406337] decode_hpp: Could not get hotplug parameters. Use defaults Oct 11 18:09:01 central kernel: [ 833.430492] virtio-pci :00:05.0: enabling device ( - 0001) Oct 11 18:09:01 central kernel: [ 833.452268] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10 Oct 11 18:09:01 central kernel: [ 833.454668] virtio-pci :00:05.0: PCI INT A - Link[LNKA] - GSI 10 (level, high) - IRQ 10 Oct 11 18:09:01 central kernel: [ 833.500051] Clocksource tsc unstable (delta = -148257950 ns) Oct 11 18:09:01 central kernel: [ 833.566755] vda: vda1 Then I attempt to remove the device assuring previously that it is not being used in guest: (qemu) pci_del 5 In the guest: Oct 11 18:13:32 central kernel: [ 1104.144179] virtio-pci :00:05.0: PCI INT A disabled But if I want to add the device again, I get a segmentation fault of the process that handles this virtual machine: (qemu) pci_add auto storage file=/dev/vm/central-test,if=virtio Connection closed by foreign host. I can actually confirm this behavior. I've been struggling with this for a couple of days now. CC'ing QEMU, as I've discussed this a bit with Anthony Liguori. There's at least two related bugs we've been tracking: * https://bugs.edge.launchpad.net/ubuntu/+source/qemu-kvm/+bug/432154 * https://bugs.edge.launchpad.net/ubuntu/+source/qemu-kvm/+bug/419590 :-Dustin -- 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: sync guest calls made async on host - SQLite performance
On Wed, Oct 7, 2009 at 2:31 PM, Matthew Tippett tippe...@gmail.com wrote: The benchmark used was the sqlite subtest in the phoronix test suite. My awareness and involvement is beyond reading a magazine article, I can elaborate if needed, but I don't believe it is necessary. Process for reproduction, assuming Karmic, # apt-get install phoronix-test-suite $ phoronix-test-suite benchmark sqlite Answer the questions (test-names, etc, etc), it will download sqlite, build it and execute the test. By default the test runs three timesand averages the results. The results experienced should be similar to the values identified at http://www.phoronix.com/scan.php?page=articleitem=linux_2631_kvmnum=3 Which is approximately 12 minutes for the native, and about 60 seconds for the guest. I have tried this, exactly as you have described. The tests took: * 1162.08033204 seconds on native hardware * 2306.68306303 seconds in a kvm using if=scsi disk * 405.382308006 seconds in a kvm using if=virtio I am using an up-to-date Karmic amd64 system, running qemu-kvm-0.11.0, on a Thinkpad x200, dual 2.4GHz, 4GB, and a somewhat slow 5400rpm SATA disk. The filesystem is ext4 in both the guest and the host. So I'm not seeing a 10x or order-of-magnitude improvement by doing this in the guest. With a scsi interface, it's twice as slow. With virtio, it's a good bit faster, but not 10x faster. That said, I don't know that I'm all that concerned about this, right now. I haven't looked in detail at what this test from phoronix is actually doing (nor do I really have the time to do so). Sorry. :-Dustin -- 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: sync guest calls made async on host - SQLite performance
On Fri, Oct 9, 2009 at 6:25 AM, Matthew Tippett tippe...@gmail.com wrote: Can I ask you to do the following... 1) Re-affirm that Ubuntu does not carry any non-stream patches and the build command and possibly any other unusual patches or commandline options. This should push it back onto Avi and Anthony's plate. I have put the patches we're carrying here, for your review: * http://rookery.canonical.com/~kirkland/patches There's nothing exotic in here. Most of these have been committed upstream already. All of them have been at least posted on these lists. None of these should affect your test case. We configure with: ./configure --prefix=/usr --disable-blobs --audio-drv-list=alsa pa oss sdl --audio-card-list=ac97 es1370 sb16 cs4231a adlib gus --target-list=$(TARGET_SYSTEM_TCG) $(TARGET_LINUX_TCG) We carry a number of compiler options, mostly in the interest of hardening and security: * https://wiki.ubuntu.com/CompilerFlags The #define'd variables on my local system (which should be similar, though not identical to our build servers) can be seen here: * http://rookery.canonical.com/~kirkland/defined 2) Carefully consider risks to virtualized environments in the server space and consider noting it in release notes. Thank you for the suggestion. I will take it under consideration. :-Dustin -- 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-devel] Re: [libvirt] dynamic scsi disk attach seems to be broken in qemu(-kvm)-0.11, libvirt-0.7.1
On Fri, Oct 9, 2009 at 9:38 AM, Anthony Liguori anth...@codemonkey.ws wrote: I would like some advice on how to proceed with this bug, and where the solution lies...in qemu or in libvirt. Ultimately, I would like the behavior we had in our previous release with kvm-84 and libvirt-0.6.1, where we could dynamically add scsi devices without a problem, using: pci_add 1 storage file=/tmp/foo,if=scsi Can anyone else reproduce this? Is this considered a regression by anyone else? Where should I look to solve this, in libvirt, or in qemu? Independently of what I said about libvirt not implementing SCSI hotplug with the right apporoach, the pci-add stuff should definitely work, so if it doesn't then this is a regression that needs to be fixed There's definitely a bug somewhere. When you add a second PCI controller, the controller shows up in the guest but the disk attached to the controller isn't visible. Rescanning the scsi bus does not make the disk appear either. Okay, thanks for confirming this, Anthony. I have added a task against upstream QEMU at: * https://bugs.edge.launchpad.net/ubuntu/+source/qemu-kvm/+bug/432154 :-Dustin -- 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: [libvirt] dynamic scsi disk attach seems to be broken in qemu(-kvm)-0.11, libvirt-0.7.1
On Fri, Oct 9, 2009 at 3:18 AM, Daniel P. Berrange berra...@redhat.com wrote: On Thu, Oct 08, 2009 at 10:57:55PM -0500, Dustin Kirkland wrote: Now, all of that said, it is actually possible to hot-add a second scsi device. However, as far as I can tell, this method is not yet supported by libvirt. It looks to me that with modern qemu, you have to do it this way: Drop to a qemu console with ctrl-alt-2. Get the address of the current scsi bus: (qemu) info pci Look for SCSI Controller. In my case, it's on Bus 0, device 4, function 0 Now instead of pci_add, use drive_add (qemu) drive_add 0:4 file=/tmp/foo,if=scsi OK bus 0, unit 1 That is correct - the SCSI driver hotplug in libvirt is not implemented in the right way. If you specify multiple SCSI devices at boot, they all get on one controller, if you hotplug multiple SCSI devices, we're hotplugging a new SCSI controller per disk. This is clearly not good, because when you then reboot, all those controllers are merged back into one. Okay, in our previous usage of this, rebooting didn't matter very much. There is a guy who is working on implementing the correct SCSI hotplug approach for libvirt, that is still work in progress though. The most recent patches were here: http://www.redhat.com/archives/libvir-list/2009-September/msg00551.html We will ultimately support hotplug of both drives, and drive controllers independantly, giving apps/users the flexibility they need. Thanks. I'll track those patches with interest. :-Dustin -- 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
dynamic scsi disk attach seems to be broken in qemu(-kvm)-0.11, libvirt-0.7.1
We're experiencing what we believe to be a regression in qemu-kvm-0.11 and libvirt-0.7.0, from previous versions of kvm-84 and libvirt-0.6.1: Dynamically attaching sdb (a second scsi disk) fails. (Note that I have tested this against libvirt-0.7.1 built from source as well--same results.) Here are some instructions to reproduce this issue: Create some small auxiliary storage to dynamically add to a running VM. (host) $ dd if=/dev/zero of=/tmp/foo bs=1M count=64 Boot a vm in under qemu-kvm-0.11.0 like this: (host) $ kvm -drive file=server.img,if=scsi,boot=on -boot c To reproduce the problem, you must use if=scsi. This problem manifests itself when subsequent scsi storage devices are added. If the device is the first scsi device on the system, then it would succeed. It's the 2nd scsi device that causes the problem. Once the system is booted, login and in the vm, load this module: (vm) $ sudo modprobe acpiphp Check that the acpiphp slots are loaded in dmesg. And note that there is only one /dev/sd[a-z] device. Now, drop to the qemu console with ctrl-alt-2, and add the storage: (qemu) pci_add auto storage file=/tmp/foo,if=scsi OK domain 0, bus 0, slot 6, function 0 Switch back to the vm linux shell with ctrl-alt-1, and look at the dmesg output. (vm) $ dmesg | tail -n 12 [ 44.033397] pci :00:06.0: reg 10 io port: [0x00-0xff] [ 44.033443] pci :00:06.0: reg 14 32bit mmio: [0x00-0x0003ff] [ 44.033486] pci :00:06.0: reg 18 32bit mmio: [0x00-0x001fff] [ 44.033899] pci :00:02.0: BAR 6: bogus alignment [0x0-0x0] flags 0x2 [ 44.033975] decode_hpp: Could not get hotplug parameters. Use defaults [ 44.042277] sym53c8xx :00:06.0: enabling device ( - 0003) [ 44.043230] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11 [ 44.043247] sym53c8xx :00:06.0: PCI INT A - Link[LNKB] - GSI 11 (level, high) - IRQ 11 [ 44.045237] sym1: 895a rev 0x0 at pci :00:06.0 irq 11 [ 44.047586] sym1: No NVRAM, ID 7, Fast-40, LVD, parity checking [ 44.055399] sym1: SCSI BUS has been reset. [ 44.063329] scsi3 : sym-2.2.3 More importantly, note that no /dev/sd[b-z] device shows up. If you now drop to the qemu console with ctrl-alt-2, and do this: (qemu) pci_add auto storage file=/tmp/foo,if=virtio OK domain 0, bus 0, slot 7, function 0 Going back to the vm with ctrl-alt-1, you can now see a new /dev/vda device registered. Now, all of that said, it is actually possible to hot-add a second scsi device. However, as far as I can tell, this method is not yet supported by libvirt. It looks to me that with modern qemu, you have to do it this way: Drop to a qemu console with ctrl-alt-2. Get the address of the current scsi bus: (qemu) info pci Look for SCSI Controller. In my case, it's on Bus 0, device 4, function 0 Now instead of pci_add, use drive_add (qemu) drive_add 0:4 file=/tmp/foo,if=scsi OK bus 0, unit 1 This is not ideal, however, as I tried re-scan the scsi bus with rescan-scsi-bus.sh (from scsitools) without luck. It did not pick up the new sdb device. However, I did reboot the vm, and voila, I now have /dev/sdb. I would like some advice on how to proceed with this bug, and where the solution lies...in qemu or in libvirt. Ultimately, I would like the behavior we had in our previous release with kvm-84 and libvirt-0.6.1, where we could dynamically add scsi devices without a problem, using: pci_add 1 storage file=/tmp/foo,if=scsi Can anyone else reproduce this? Is this considered a regression by anyone else? Where should I look to solve this, in libvirt, or in qemu? -- :-Dustin -- 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: sync guest calls made async on host - SQLite performance
On Wed, Oct 7, 2009 at 11:53 AM, Matthew Tippett tippe...@gmail.com wrote: When you indicated that you had attempted to reproduce the problem, what mechanism did you use? Was it Karmic + KVM as the host and Karmic as the guest? What test did you use? I ran the following in several places: a) on the system running on real hardware, time dd if=/dev/zero of=$HOME/foo bs=1M count=500 524288000 bytes (524 MB) copied, 9.72614 s, 53.9 MB/s b) in an vm running on qemu-kvm-0.11 on Karmic time dd if=/dev/zero of=$HOME/foo bs=1M count=500 oflag=direct 524288000 bytes (524 MB) copied, 31.6961 s, 16.5 MB/s c) in a vm running on kvm-84 on Jaunty time dd if=/dev/zero of=$HOME/foo bs=1M count=500 oflag=direct 524288000 bytes (524 MB) copied, 22.2169 s, 23.6 MB/s Looking at the time it takes to write a 500MB file to a real hard disk, and then inside of the VM. If I were to experience the problem on Karmic, I would have seen this dd of a 500MB file take far, far less time than it takes to write that file to disk on the real hardware. This was not the case in my testing. I will re-open the launchpad bug if you believe it makes sense to continue the discussions there. Please re-open the bug if you can describe a real test case that you used to demonstrate the problem. Without being rude, it's hard for me to work from a bug that says a magazine article says that there's a bug in the Ubuntu distribution of qemu-kvm-0.11. If you can provide clear steps that you have used to experience the problem, then I will be able to take this issue seriously, reproduce it myself, and develop a fix. :-Dustin -- 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: sync guest calls made async on host - SQLite performance
On Tue, Sep 29, 2009 at 2:32 PM, Matthew Tippett tippe...@gmail.com wrote: I would prefer rather than riling against Phoronix or the results as presented, ask questions to seek further information about what was tested rather than writing off all of it as completely invalid. Matthew- If you could please provide very specific instructions that you have personally used to reproduce this problem on the latest Ubuntu Karmic qemu-kvm-0.11.0 package, that would help very much. I have personally tried to reproduce this problem and I don't see the problem manifested in Ubuntu's qemu-kvm package. For the technical people on the list, our configure line in Ubuntu looks like this: ./configure --prefix=/usr --disable-blobs --audio-drv-list=alsa pa oss sdl --audio-card-list=ac97 es1370 sb16 cs4231a adlib gus ... I don't think we're doing anything exotic, and we're not carrying any major patches. I have submitted each patch that we are carrying upstream to the KVM and/or QEMU mailing lists as appropriate. :-Dustin -- 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: [ANNOUNCE] qemu-kvm-0.11.0 released
On Sun, Sep 27, 2009 at 2:42 AM, Avi Kivity a...@redhat.com wrote: qemu-kvm-0.11.0 is now available. This release is is based on the upstream qemu 0.11.0, plus kvm-specific enhancements. Thanks, Avi. We in Ubuntu have tracked each of the two previous RC's, and we will have this GA version in Karmic within a day or so. We're looking forward to following the stable branch as opposed to the kvm-NN snapshots we've traditionally tracked. :-Dustin -- 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: [ANNOUNCE] qemu-kvm-0.11.0 released
On Wed, 2009-09-30 at 01:48 +0400, Michael Tokarev wrote: Dustin Kirkland wrote: On Sun, Sep 27, 2009 at 2:42 AM, Avi Kivity a...@redhat.com wrote: qemu-kvm-0.11.0 is now available. This release is is based on the upstream qemu 0.11.0, plus kvm-specific enhancements. Thanks, Avi. We in Ubuntu have tracked each of the two previous RC's, and we will have this GA version in Karmic within a day or so. We're looking forward to following the stable branch as opposed to the kvm-NN snapshots we've traditionally tracked. By the way, I maintain Debian kvm packages for quite some time (because debian does not have up-to-date kvm), all are available here -- http://www.corpit.ru/debian/tls/kvm/. Anything wrong with those, have you seen them? Just... asking :) Hmm, no, I haven't seen those. I looked for Debian qemu-kvm packages at: * http://packages.qa.debian.org/q/qemu-kvm.html * http://mentors.debian.net/cgi-bin/welcome Didn't find any, and so we decided to roll our own to ensure that we got qemu-kvm into Karmic. :-Dustin signature.asc Description: This is a digitally signed message part
Re: Release plan for 0.12.0
On Tue, Sep 29, 2009 at 6:54 PM, Anthony Liguori aligu...@us.ibm.com wrote: Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0. I'd like to do a few things different this time around. I don't think the -rc process went very well as I don't think we got more testing out of it. I'd like to shorten the timeline for 0.12.0 a good bit. The 0.10 stable tree got pretty difficult to maintain toward the end of the cycle. We also had a pretty huge amount of change between 0.10 and 0.11 so I think a shorter cycle is warranted. I think aiming for early to mid-December would give us roughly a 3 month cycle and would align well with some of the Linux distribution cycles. I'd like to limit things to a single -rc that lasted only for about a week. This is enough time to fix most of the obvious issues I think. As a downstream packager of qemu-kvm, I thought I'd mention that the next Ubuntu cycle is now public: * https://wiki.ubuntu.com/LucidReleaseSchedule The key date here is Feature Freeze, which is February 25, 2010. That's the point by which we'd need to have a new qemu-kvm (which of course is downstream of qemu) package in Ubuntu for the LTS 10.04 release in April 2010. I'll gladly track the release candidate(s) in the Lucid development tree, and hopefully pull 0.12 as soon as its available. And we also provide daily snapshots of qemu builds at: * https://edge.launchpad.net/~ubuntu-virt/+archive/virt-daily-upstream :-Dustin -- 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
[PATCH] update qemu-ifup for modern ip route output
update qemu-ifup for modern ip route output
The output from the /sbin/ip utility has changed, adding two
more columns, which breaks the qemu-ifup script, as it was
depending on the last column being the interface name.
Change this from $NF to $5.
https://bugs.edge.launchpad.net/ubuntu/+source/qemu-kvm/+bug/430652
Signed-off-by: Dustin Kirkland kirkl...@canonical.com
---
kvm/scripts/qemu-ifup |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kvm/scripts/qemu-ifup b/kvm/scripts/qemu-ifup
index 3bf8801..284b176 100755
--- a/kvm/scripts/qemu-ifup
+++ b/kvm/scripts/qemu-ifup
@@ -1,5 +1,5 @@
#!/bin/sh
-switch=$(/sbin/ip route list | awk '/^default / { print $NF }')
+switch=$(/sbin/ip route list | awk '/^default / { print $5 }')
/sbin/ifconfig $1 0.0.0.0 up
/usr/sbin/brctl addif ${switch} $1
--
1.6.3.3
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] qemu-kvm: fix segfault when running kvm without /dev/kvm, falling back to non-accelerated mode
On Fri, 2009-09-04 at 08:22 +0100, Mark McLoughlin wrote: On Thu, 2009-09-03 at 19:18 -0300, Glauber Costa wrote: On Thu, Sep 3, 2009 at 6:48 PM, Dustin Kirklandkirkl...@canonical.com wrote: On Thu, Sep 3, 2009 at 3:01 PM, Mark McLoughlinmar...@redhat.com wrote: On Thu, 2009-09-03 at 12:31 -0500, Dustin Kirkland wrote: qemu-kvm: fix segfault when running kvm without /dev/kvm, falling back to non-accelerated mode We're seeing segfaults on systems without access to /dev/kvm. It looks like the global kvm_allowed is being set just a little too late in vl.c. This patch moves the kvm initialization a bit higher in the vl.c main, just after options processing, and solves the segfaults. We're carrying this patch in Ubuntu 9.10 Alpha. Please apply upstream, or advise if and why this might not be the optimal solution. Ah discussion about an alternative fix for this fizzled out recently: http://www.mail-archive.com/kvm@vger.kernel.org/msg19890.html Ah, thanks Mark. In that thread, I found Daniel's suggestion the most reasonable, and user-friendly: On Mon, Jul 27, 2009 at 1:44 PM, Daniel P. Berrangeberra...@redhat.com wrote: Well, we could go for logic like: * No arg given = try kvm, try kqemu, try tcg * --accelmode arg given = try $arg, and fail if unavailable then libvirt would simply always supply --accelmode for all VMs, while people running qemu manually would get best available I sent some patches to do that, but they were incomplete, and I was preempted by something else. If you want, you can wait for my cycles to come back, or pick from where I left Thanks for the pointer, Glauber. My cycles a bit constrained too, but I'll have a look when I get a chance. In the meantime, can we commit to stable-0.11 either Dustin's fix or this: http://git.et.redhat.com/?p=qemu-fedora.git;a=commitdiff;h=aa1620047b +1. We're looking for something agreeable in stable-0.11, that solves the segfault and proceeds without VT acceleration. -- :-Dustin Dustin Kirkland Canonical, LTD kirkl...@canonical.com GPG: 1024D/83A61194 signature.asc Description: This is a digitally signed message part
Re: [PATCH] qemu-kvm: fix segfault when running kvm without /dev/kvm, falling back to non-accelerated mode
On Fri, Sep 4, 2009 at 11:36 AM, Marcelo Tosattimtosa...@redhat.com wrote:
On Fri, Sep 04, 2009 at 11:06:38AM -0500, Dustin Kirkland wrote:
On Fri, 2009-09-04 at 08:22 +0100, Mark McLoughlin wrote:
On Thu, 2009-09-03 at 19:18 -0300, Glauber Costa wrote:
On Thu, Sep 3, 2009 at 6:48 PM, Dustin Kirklandkirkl...@canonical.com
wrote:
On Thu, Sep 3, 2009 at 3:01 PM, Mark McLoughlinmar...@redhat.com
wrote:
On Thu, 2009-09-03 at 12:31 -0500, Dustin Kirkland wrote:
qemu-kvm: fix segfault when running kvm without /dev/kvm, falling
back
to non-accelerated mode
We're seeing segfaults on systems without access to /dev/kvm. It
looks like the global kvm_allowed is being set just a little too late
in vl.c. This patch moves the kvm initialization a bit higher in the
vl.c main, just after options processing, and solves the segfaults.
We're carrying this patch in Ubuntu 9.10 Alpha. Please apply
upstream, or advise if and why this might not be the optimal
solution.
Ah discussion about an alternative fix for this fizzled out recently:
http://www.mail-archive.com/kvm@vger.kernel.org/msg19890.html
Ah, thanks Mark. In that thread, I found Daniel's suggestion the most
reasonable, and user-friendly:
On Mon, Jul 27, 2009 at 1:44 PM, Daniel P.
Berrangeberra...@redhat.com wrote:
Well, we could go for logic like:
* No arg given = try kvm, try kqemu, try tcg
* --accelmode arg given = try $arg, and fail if unavailable
then libvirt would simply always supply --accelmode for all VMs,
while people running qemu manually would get best available
I sent some patches to do that, but they were incomplete, and I was
preempted by something else.
If you want, you can wait for my cycles to come back, or pick from where
I left
Thanks for the pointer, Glauber. My cycles a bit constrained too, but
I'll have a look when I get a chance.
In the meantime, can we commit to stable-0.11 either Dustin's fix or
this:
http://git.et.redhat.com/?p=qemu-fedora.git;a=commitdiff;h=aa1620047b
+1. We're looking for something agreeable in stable-0.11, that solves
the segfault and proceeds without VT acceleration.
Dustin,
Can you please resend the patch with the suggestion i made earlier, for
stable-0.11?
Sure, Marcelo. It's attached.
I tested it, and it still does avoid the segfault.
Luiz, could you re-test this patch on your side too?
:-Dustin
qemu-kvm: fix segfault when running kvm without /dev/kvm
qemu-kvm segfaults on systems without access to /dev/kvm.
The global kvm_allowed is being set too late in vl.c.
This patch moves the kvm initialization a bit higher in the
vl.c main, just after the daemonize fork.
This fix is intended to be a short term solution, solving the
segfaults.
In the longer term, the suggested approach requires a bit more
development and testing:
* If no arg given = try kvm, try kqemu, try tcg
* If --accelmode arg given = try $arg, and fail if unavailable
Signed-off-by: Dustin Kirkland kirkl...@canonical.com
diff --git a/vl.c b/vl.c
index db75470..26bced8 100644
--- a/vl.c
+++ b/vl.c
@@ -5831,6 +5831,20 @@ int main(int argc, char **argv, char **envp)
}
#endif
+if (kvm_enabled()) {
+int ret;
+
+ret = kvm_init(smp_cpus);
+if (ret 0) {
+#if defined(KVM_UPSTREAM) || defined(NO_CPU_EMULATION)
+fprintf(stderr, failed to initialize KVM\n);
+exit(1);
+#endif
+fprintf(stderr, Could not initialize KVM, will disable KVM support\n);
+kvm_allowed = 0;
+}
+}
+
#ifdef CONFIG_KQEMU
if (smp_cpus 1)
kqemu_allowed = 0;
@@ -6002,20 +6016,6 @@ int main(int argc, char **argv, char **envp)
}
}
-if (kvm_enabled()) {
-int ret;
-
-ret = kvm_init(smp_cpus);
-if (ret 0) {
-#if defined(KVM_UPSTREAM) || defined(NO_CPU_EMULATION)
-fprintf(stderr, failed to initialize KVM\n);
-exit(1);
-#endif
-fprintf(stderr, Could not initialize KVM, will disable KVM support\n);
- kvm_allowed = 0;
-}
-}
-
if (monitor_device) {
monitor_hd = qemu_chr_open(monitor, monitor_device, NULL);
if (!monitor_hd) {
[PATCH] qemu-kvm: fix segfault when running kvm without /dev/kvm, falling back to non-accelerated mode
qemu-kvm: fix segfault when running kvm without /dev/kvm, falling back
to non-accelerated mode
We're seeing segfaults on systems without access to /dev/kvm. It
looks like the global kvm_allowed is being set just a little too late
in vl.c. This patch moves the kvm initialization a bit higher in the
vl.c main, just after options processing, and solves the segfaults.
We're carrying this patch in Ubuntu 9.10 Alpha. Please apply
upstream, or advise if and why this might not be the optimal solution.
Signed-off-by: Dustin Kirkland kirkl...@canonical.com
Move the kvm_init() call a bit higher to fix a segfault when
/dev/kvm is not available. The kvm_allowed global needs
to be set correctly a little earlier.
Signed-off-by: Dustin Kirkland kirkl...@canonical.com
--- qemu-kvm-0.11.0~rc1.orig/vl.c
+++ qemu-kvm-0.11.0~rc1/vl.c
@@ -5748,6 +5748,20 @@
}
}
+if (kvm_enabled()) {
+int ret;
+
+ret = kvm_init(smp_cpus);
+if (ret 0) {
+#if defined(KVM_UPSTREAM) || defined(NO_CPU_EMULATION)
+fprintf(stderr, failed to initialize KVM\n);
+exit(1);
+#endif
+fprintf(stderr, Could not initialize KVM, will disable KVM support\n);
+kvm_allowed = 0;
+}
+}
+
/* If no data_dir is specified then try to find it relative to the
executable path. */
if (!data_dir) {
@@ -6008,20 +6022,6 @@
}
}
-if (kvm_enabled()) {
-int ret;
-
-ret = kvm_init(smp_cpus);
-if (ret 0) {
-#if defined(KVM_UPSTREAM) || defined(NO_CPU_EMULATION)
-fprintf(stderr, failed to initialize KVM\n);
-exit(1);
-#endif
-fprintf(stderr, Could not initialize KVM, will disable KVM support\n);
- kvm_allowed = 0;
-}
-}
-
if (monitor_device) {
monitor_hd = qemu_chr_open(monitor, monitor_device, NULL);
if (!monitor_hd) {
Re: [PATCH] qemu-kvm: fix segfault when running kvm without /dev/kvm, falling back to non-accelerated mode
On Thu, Sep 3, 2009 at 3:01 PM, Mark McLoughlinmar...@redhat.com wrote: On Thu, 2009-09-03 at 12:31 -0500, Dustin Kirkland wrote: qemu-kvm: fix segfault when running kvm without /dev/kvm, falling back to non-accelerated mode We're seeing segfaults on systems without access to /dev/kvm. It looks like the global kvm_allowed is being set just a little too late in vl.c. This patch moves the kvm initialization a bit higher in the vl.c main, just after options processing, and solves the segfaults. We're carrying this patch in Ubuntu 9.10 Alpha. Please apply upstream, or advise if and why this might not be the optimal solution. Ah discussion about an alternative fix for this fizzled out recently: http://www.mail-archive.com/kvm@vger.kernel.org/msg19890.html Ah, thanks Mark. In that thread, I found Daniel's suggestion the most reasonable, and user-friendly: On Mon, Jul 27, 2009 at 1:44 PM, Daniel P. Berrangeberra...@redhat.com wrote: Well, we could go for logic like: * No arg given = try kvm, try kqemu, try tcg * --accelmode arg given = try $arg, and fail if unavailable then libvirt would simply always supply --accelmode for all VMs, while people running qemu manually would get best available :-Dustin -- 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-88 broke VirtIO Hard Disks
On Thu, Jul 23, 2009 at 9:23 AM, Alexey Eromenkoaerom...@redhat.com wrote: - Marcelo Tosatti mtosa...@redhat.com wrote: On Thu, Jul 23, 2009 at 07:37:37AM -0400, Alexey Eromenko wrote: Hi All ! In addition to Floppy controllers KVM-88 also break VirtIO hard disks. (Windows 2003 Drivers refuse to work now) Linux (RHEL 5.3/x64) still boots off VirtIO Hard Disk. It turned out to be a Qemu merge into KVM userspace: kvm-87-119-ga8b7f95 (commit a8b7f959d1fd97c4ccaf08ce750020ecd08b4c88) Can you look into it? Not sure if you familiar with this, but anyway: $ git diff-tree -p bf011293f | patch -R -p1 Yes, Thanks, This is it ! This is the problem. I, too, can confirm that reverting this commit solves the same problem for me. Having reverted the commit, I can once again boot with virtio disks. :-Dustin -- 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
daily builds of pristine upstream sources for qemu, qemu-kvm, and libvirt
Howdy, developers of qemu, qemu-kvm, and libvirt. I periodically see bug reports on these lists from users of Ubuntu packages of these projects. Since these users are often running some version of the project older than the current development branch, it's more interesting to know if the user can reproduce the bug on the latest development sources. I have constructed some automation that builds Debian/Ubuntu binaries for amd64, i386, and lpia platforms directly from your master git repositories every day at 11:00 UTC, and publishes them in a special, opt-in repository. These daily builds also drop any specific patches we may be carrying, in order to minimize the delta between the binaries built and your upstream sources. * https://launchpad.net/~ubuntu-virt/+archive/virt-daily-upstream In the event that an Ubuntu user reports a problem, and there's an interest in trying to reproduce the problem against the tip of the development branch, we can point them at this resource for testing purposes. Additionally, this tool also has the ability to expose build breakages. For example (let's not debug this in this thread), at the moment, qemu's build is broken, somewhere near: LINK cris-softmmu/qemu-system-cris ../libqemu_common.a(esdaudio.o): In function `qesd_run_in': /build/buildd/qemu-0.10.50.20090707062004/audio/esdaudio.c:400: undefined reference to `audio_pt_lock' Launchpad publishes the full build logs available for each architecture at the link above. For the above example, the specific build log is: * http://launchpadlibrarian.net/28761559/buildlog_ubuntu-karmic-amd64.qemu_0.10.50.20090707062004-0daily1_FAILEDTOBUILD.txt.gz If anyone has suggestions as to the utility of this resource, I would appreciate constructive feedback. Cheers, -- :-Dustin -- 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 on Ubuntu 8.04 running windows xp sp3: corrupts file system on shutdown?
On Thu, Jul 2, 2009 at 8:53 AM, Yaniv Kaulyk...@redhat.com wrote: On 7/2/2009 6:50 PM, Jon Watte wrote: I'm attempting to set up a Windows XP virtual machine using KVM running on 8.04 LTS x64 or a Core 2 Duo (6550). I have updated all installed packages to the latest available as of a week ago. This is KVM version 0.9.1 (kvm-62) on a kernel version 2.6.24-22-server. I warmly suggest updating to a later, much newer, KVM version. Specifically qcow2 format had corruption bugs similar to what described below. I second Yaniv's comment. I am working on a backport of kvm-84 (kernel and userspace) to Ubuntu 8.04 LTS. You can try the kvm packages in the following personal package archive (PPA): * https://launchpad.net/~ubuntu-virt/+archive/ppa Or, you can wait about a week and these packages should be uploaded to the hardy-backports archive, and you can install from there, rather than from the PPA. Please install both kvm and kvm-source to update both user and kernel space. (Note that these packages contain cherry picks of the qcow2 corruption patches.) :-Dustin -- 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: [PATCH] qemu-kvm: fix typo in configure
On Wed, Jul 1, 2009 at 4:27 AM, Michael S. Tsirkinm...@redhat.com wrote:
Kill extra \). Also escape ! for clarity and bourne shell
compatibility.
Agreed. Looks like this one was introduced during the last merge from
qemu. It bit me too.
:-Dustin
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
This patch fixes configure on next for me
configure | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/configure b/configure
index f76f511..b62e3d7 100755
--- a/configure
+++ b/configure
@@ -2141,10 +2141,10 @@ configure_kvm() {
}
# Make sure the target and host cpus are compatible
-if test ! \( $target_cpu = $cpu -o \
+if test \! \( $target_cpu = $cpu -o \
\( $target_cpu = ppcemb -a $cpu = ppc \) -o \
- \( $target_cpu = x86_64 -a $cpu = i386 \) -o \
- \( $target_cpu = i386 -a $cpu = x86_64 \) \) -o \
+ \( $target_cpu = x86_64 -a $cpu = i386 \) -o \
+ \( $target_cpu = i386 -a $cpu = x86_64 \) -o \
\( $target_cpu = ia64 -a $cpu = ia64 \) \) ; then
target_kvm=no
fi
--
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: [PATCH] Fix non-KVM build
On Wed, Jun 24, 2009 at 1:13 PM, Anthony Liguorialigu...@us.ibm.com wrote: This introduces some #ifdefs in pcspk to fix the build when KVM isn't enabled. Signed-off-by: Anthony Liguori aligu...@us.ibm.com --- hw/pcspk.c | 15 +-- 1 files changed, 9 insertions(+), 6 deletions(-) ... Thanks, Anthony. This patch does solve my pcspk build breakage, and gets me a bit further in the build, before: ... CCppc-softmmu/disas.o CCppc-softmmu/i386-dis.o CCppc-softmmu/ppc-dis.o ARppc-softmmu/libqemu.a LINK ppc-softmmu/qemu-system-ppc machine.o: In function `cpu_load': /tmp/tmp.wibDyxlHPK/qemu-kvm-0.10.50.20090624132948/target-ppc/machine.c:180: undefined reference to `cpu_synchronize_state' machine.o: In function `cpu_save': /tmp/tmp.wibDyxlHPK/qemu-kvm-0.10.50.20090624132948/target-ppc/machine.c:10: undefined reference to `cpu_synchronize_state' ppc440.o: In function `ppc440ep_init': /tmp/tmp.wibDyxlHPK/qemu-kvm-0.10.50.20090624132948/hw/ppc440.c:48: undefined reference to `kvm_enabled' ppc440_bamboo.o: In function `bamboo_init': /tmp/tmp.wibDyxlHPK/qemu-kvm-0.10.50.20090624132948/hw/ppc440_bamboo.c:183: undefined reference to `kvm_enabled' /tmp/tmp.wibDyxlHPK/qemu-kvm-0.10.50.20090624132948/hw/ppc440_bamboo.c:184: undefined reference to `kvmppc_init' ppce500_mpc8544ds.o: In function `mpc8544ds_init': /tmp/tmp.wibDyxlHPK/qemu-kvm-0.10.50.20090624132948/hw/ppce500_mpc8544ds.c:277: undefined reference to `kvm_enabled' /tmp/tmp.wibDyxlHPK/qemu-kvm-0.10.50.20090624132948/hw/ppce500_mpc8544ds.c:278: undefined reference to `kvmppc_init' libqemu.a(helper.o): In function `ppc_tlb_invalidate_all': /tmp/tmp.wibDyxlHPK/qemu-kvm-0.10.50.20090624132948/target-ppc/helper.c:1861: undefined reference to `kvm_enabled' collect2: ld returned 1 exit status make[2]: *** [qemu-system-ppc] Error 1 make[1]: *** [subdir-ppc-softmmu] Error 2 :-Dustin -- 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: [PATCH] Only compile KVM support for matching CPU types
On Wed, 2009-06-24 at 17:40 -0500, Anthony Liguori wrote:
I don't know why this is disabled for qemu-kvm.git.
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
---
configure |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/configure b/configure
index 4bad3c3..1b73eaf 100755
--- a/configure
+++ b/configure
@@ -2117,13 +2117,12 @@ configure_kvm() {
fi
}
-if [ use_upstream_kvm = yes ]; then
-
# Make sure the target and host cpus are compatible
if test ! \( $target_cpu = $cpu -o \
\( $target_cpu = ppcemb -a $cpu = ppc \) -o \
\( $target_cpu = x86_64 -a $cpu = i386 \) -o \
\( $target_cpu = i386 -a $cpu = x86_64 \) \) ; then
+ \( $target_cpu = ia64 -a $cpu = ia64 \) \) ; then
Almost...
- \( $target_cpu = i386 -a $cpu = x86_64 \) \) ; then
+ \( $target_cpu = i386 -a $cpu = x86_64 \) \) -o \
+ \( $target_cpu = ia64 -a $cpu = ia64 \) \) ; then
:-Dustin
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] Only compile KVM support for matching CPU types
On Wed, 2009-06-24 at 18:09 -0500, Dustin Kirkland wrote: On Wed, 2009-06-24 at 17:40 -0500, Anthony Liguori wrote: # Make sure the target and host cpus are compatible if test ! \( $target_cpu = $cpu -o \ \( $target_cpu = ppcemb -a $cpu = ppc \) -o \ \( $target_cpu = x86_64 -a $cpu = i386 \) -o \ \( $target_cpu = i386 -a $cpu = x86_64 \) \) ; then + \( $target_cpu = ia64 -a $cpu = ia64 \) \) ; then Almost... - \( $target_cpu = i386 -a $cpu = x86_64 \) \) ; then + \( $target_cpu = i386 -a $cpu = x86_64 \) \) -o \ + \( $target_cpu = ia64 -a $cpu = ia64 \) \) ; then Doh. Still not quite right... Clean patch below. Signed-off-by: Dustin Kirkland kirkl...@canonical.com === modified file 'configure' --- configure 2009-06-17 11:16:33 + +++ configure 2009-06-24 23:13:00 + @@ -2117,13 +2117,12 @@ fi } -if [ use_upstream_kvm = yes ]; then - # Make sure the target and host cpus are compatible if test ! \( $target_cpu = $cpu -o \ \( $target_cpu = ppcemb -a $cpu = ppc \) -o \ \( $target_cpu = x86_64 -a $cpu = i386 \) -o \ - \( $target_cpu = i386 -a $cpu = x86_64 \) \) ; then + \( $target_cpu = i386 -a $cpu = x86_64 \) -o \ + \( $target_cpu = ia64 -a $cpu = ia64 \) \) ; then target_kvm=no fi # Disable KVM for linux-user @@ -2131,8 +2130,6 @@ target_kvm=no fi -fi - case $target_cpu in i386) echo TARGET_ARCH=i386 $config_mak signature.asc Description: This is a digitally signed message part
Re: [Qemu-devel] QEMU bug tracker on Launchpad
On Tue, 2009-06-23 at 20:02 +0300, Blue Swirl wrote: On 6/23/09, Anthony Liguori aligu...@us.ibm.com wrote: Dustin Kirkland was kind enough to setup a bug tracker for QEMU on Launchpad. I would like to make this the official QEMU bug tracker unless there is significant objection. The links on code tab do not show which is our tree and there are some Ubuntu trees: https://code.launchpad.net/qemu Can that be fixed? This 'code' tab does not yet support git. The trees you're seeing are bzr. I don't think Anthony has any intention of using the bzr functions of Launchpad, and the qemu git tree will remain at git://git.savannah.nongnu.org/qemu.git. For convenience, I have setup a periodic sync of the latest git (using git fast-export | bzr fast-import -). I'll move the Ubuntu trees elsewhere, sorry for the noise. :-Dustin signature.asc Description: This is a digitally signed message part
Re: Kvm crash when I create a Guest
On Tue, Apr 7, 2009 at 2:15 AM, Alessio Rocchi alessio.roc...@staff.dada.net wrote: I'm Running Ubuntu 8.10, here is the command I use: kvm -net none -m 192 -no-acpi -hda ./gentoo_cleanvm.img.tar.lzma Ubuntu 8.10 uses kvm-72 by default. You might, perhaps, try kvm-84, which is more current and fixes a number of issues. You can try the pre-built packages available for Ubuntu 8.10 at: * https://launchpad.net/~ubuntu-virt/+archive/ppa You should install both the kvm and the kvm-source package, which would get you kvm-84 userspace and the kernel module. :-Dustin -- 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-84 + virtio Ubuntu Hardy guests
On Mon, 2009-04-06 at 18:43 +0100, Mark McLoughlin wrote: The problem here is that 2.6.24/5 vintage guests are saying they support something they don't. See this for further details: http://lists.gnu.org/archive/html/qemu-devel/2009-01/msg00574.html Agreed, understood. And those kernels should be patched. However, it's a bit of a chicken/egg problem... One can't even boot those guests (with virtio) to update the kernel, as it panics on boot (without the kvm hack). :-Dustin -- 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
kvm-84 + virtio Ubuntu Hardy guests
Howdy kvm- I'm receiving a heavy volume of Ubuntu Jaunty Beta users reporting that Jaunty hosts running kvm-84 (userspace and kernel) are not able to boot previously-working Hardy guests (2.6.24 kernel) if virtio networking is enabled [1]. Users report that if e1000 is used instead, the guest is able to boot (with degraded network performance, obviously). Users are also reporting that this was not a problem when kvm-82 was used in Jaunty (though we also merged libvirt 0.5.1 up to 0.6.0 in roughly the same timeframe). It's unclear to me, at this point, if this is a kvm or libvirt problem. I personally have not been able to reproduce this problem with kvm alone. However, I'm curious if anyone else here is familiar with this issue, or has seen something similar? [1] https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/331128 Thanks, -- :-Dustin -- 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-84 screen corruption
On Tue, Feb 24, 2009 at 8:47 PM, Zhang, Xiantao xiantao.zh...@intel.com wrote: I can confirm it on ia64 platform with kvm-84 and kvm-userspace upstream source. Another issue is that the text color is not correct. For what it's worth, I was able to fix this in kvm (1:84+dfsg-0ubuntu5) jaunty by applying: * http://svn.savannah.gnu.org/viewvc/trunk/exec.c?r1=6601r2=6628pathrev=6628root=qemuview=patch That patch was attached to: * http://sourceforge.net/tracker/?func=detailatid=893831aid=2556746group_id=180599 :-Dustin -- 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-84 screen corruption
On Tue, Feb 24, 2009 at 12:01 PM, Aurelien Jarno aurel...@aurel32.net wrote: This is most probably fixed in git, commit 7def4ba752cf629043e884dac8541fa5114c4c91 Great. Which git? I checked: * git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git And I noticed Debian in your sig, so I also checked: * git://git.debian.org/git/collab-maint/kvm.git Don't see it... :-Dustin -- 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-84 screen corruption
On Tue, Feb 24, 2009 at 3:29 PM, Anthony Liguori anth...@codemonkey.ws wrote: kvm-userspace.git. That changeset merged against QEMU SVN which is where the fix really happened. Okay, hmm... I've applied this fix (plus another queued one that Anthony sent my way). I'm still seeing the screen corruption. The easily way to reproduce it, as I said before, seems to be cat'ing a file. I've been using `cat /proc/cpuinfo`. And I've notice that this happens on the 7th invocation after a fresh boot, every time. :-Dustin -- 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: [PATCH] use KVM_UPSTREAM for ppc.
On 2/13/09, Glauber Costa glom...@redhat.com wrote: ppc should compile with upstream qemu code, so, put these defines in ppc specific code that references kvm functions. We don put them in config.h in this case, since there are files (like vl.c) that includes both kvm.h and qemu-kvm.h, and would break compilation. Ack. This patch is required for Ubuntu packaging of kvm-84. Otherwise, the compilation is broken. Thanks for this. :-Dustin -- 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: [PATCH] include qemu-kvm.h at all cases.
On 2/12/09, Glauber Costa glom...@redhat.com wrote: We don't have any kind of kvm support for linux-user targets, but conditionalizing the inclusion of kvm header make linux-user compilation break. And we don't have a reason to prevent that, do we? Ack, again, same problem here. The lack of inclusion of this header breaks the build of kvm-84 for the Ubuntu package. :-Dustin -- 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-83
On Thu, Jan 22, 2009 at 5:24 PM, Gioacchino Mendola gioacchino.mend...@gmail.com wrote: but I have some problems, since guest freezes at boot time (at very early stage since it does not print any message on the attached vnc) and /var/log/messages sports the following error message: kvm: 4982: cpu0 unhandled wrmsr: 0xc0010117 data 0 We're seeing this same error in Ubuntu's kvm-83 as well, * https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/325851 It seems benign, on this side. No lockups here, that I'm noticing. What does this error message mean? Is it something that we should be concerned about? :-Dustin -- 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
