Hi,
I'm having trouble getting kvm to work on my system.
The host has 2 dual-core Intel Xeon 5130 CPUs (flags: lm vmx)
and is running Linux 2.6.20.1 with kvm-15 (although I've had no luck
with kvm-12 or kvm-14 either)
If I take (for example) the NetBSD amd64 installation:
ftp://ftp.netbsd.org
Avi Kivity wrote:
> >Also, on the Linux side of things, I have a disk image from a computer
> >that also crashes when I try to boot it. It dies with "exception 14"
> >after Grub. But, it does work fine with -no-kvm. The kernel it's
> >booting is a 32-bit k7 optimized kernel; is it expected beha
> I like to have only the latest versions of software installed
> here. For me, it doesn't make sense to use gcc3 only to be able to
> compile qemu, since I'll not use it on any other software.
Why not install them both? Most distributions make it quite easy.
For Debian/Ubunty, "apt-get ins
> On the gname archive its even worse the @@ get converted to
> as they must think its an email address. So it looks
> like the archives are a poor place to pickup patches, at least
> for me.
..
> Sorry for any confusion but the upshot is still that the archives are
> unable to be used for retrie
http://kvm.qumranet.com/kvmwiki/Migration suggests to use
stop
migrate "exec:dd of=STATEFILE"
to save an image that can be loaded later. I was having trouble
getting this to work (loading gave "Migration failed rc=233") and
discovered that not all of the data was being saved, probably becau
I wrote:
> migrate "exec:dd of=STATEFILE"
> ... I was having trouble getting this to work (loading gave
> "Migration failed rc=233") and discovered that not all of the data
> was being saved, probably because of some buffering/pipe issues.
Actually, maybe that isn't the issue. I guess the migra
I wrote:
> It's almost as if migrate_write() is being called after
> migrate_finish() ??
Yes, I'm definitely seeing this -- migrate_finish followed by
migrate_write, which causes a segfault (and explains my truncated
images). Unfortunately I'm not at all familiar with this code, and
all the qemu
If *has_error==0, s is freed before s->detach is used. Save a copy of
s->detach earlier.
Signed-off-by: Jim Paris <[EMAIL PROTECTED]>
---
This shouldn't change much since the memory is most likely still
valid even after it's been freed, but it's still a bug.
qem
If readline_handle_byte() is sent both a CR and LF, and
readline_start() is not called after the first CR, then the LF will
cause the same command to be executed a second time. Fix this by
explicitly resetting the buffer pointer when it is processed.
Signed-off-by: Jim Paris <[EMAIL PROTEC
I think I've (finally!) tracked it down. See the attached patches.
The main problem is this: when using "-monitor pty", all incoming
commands are terminated with CRLF even though they were sent with just
LF, probably because of the pty layer somewhere. When qemu's readline
gets CR and LF without
Signed-off-by: Jim Paris <[EMAIL PROTECTED]>
---
Having two migrations run simultaneously was causing my crashes.
The command was sent twice because of a bug in the readline routines,
but adding a check here as well seems like a good idea.
qemu/migration.c |6 ++
1 files chan
Extends option syntax to allow "-incoming file://" for
file-based migration.
Signed-off-by: Jim Paris <[EMAIL PROTECTED]>
---
For some applications (e.g. qemu launched by libvirt) it's much easier
to just pass a filename on the commandline than to feed data via
stdin.
qe
Hi,
Could qemu/VERSION get updated with each KVM release? Currently it
seems there is no way to determine the KVM version from the binaries.
Putting it in MODULE_VERSION for the kernel modules would also be
useful.
-jim
-
Without this, memory is leaked and later attempts fail with
"Migration already active".
Signed-off-by: Jim Paris <[EMAIL PROTECTED]>
---
qemu/migration.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/qemu/migration.c b/qemu/migration.c
index bbeed86
by term_update() before the next prompt.
Signed-off-by: Jim Paris <[EMAIL PROTECTED]>
---
Avi, this goes along with 076e405adda6b47563e23ac24b57c8bb8ba55488,
"qemu: reset buffer pointers after CR/LF", which wasn't quite complete.
Thanks.
qemu/readline.c |2 ++
1 files
Uri Lublin wrote:
> There is still the mystery of different file sizes for different
> migration-exec commands, all files are "valid saved image".
> It seems to me that some unmodified pages are being marked as dirty, and
> are being saved twice (and later loaded twice).
> I'm still chasing that.
I wrote
> I looked into this a bit more and it seems that a big piece of
> migration.c is missing or broken.
..
> Am I missing something?
Yes, I am. Sorry, I missed the qemu_live_savevm_state call, which
saves the rest of the dirty pages, and explains why some migration
images are larger than oth
> And regarding the patches in the dos format, I tried sending patches to
> my yahoo/gmail account and I don't see them in the DOS format. It's
> strange it is reaching you in the DOS format. I don't know a way to
> avoid it right now. Please let me know if there is any known trick or
> method to a
Carlo Marcelo Arenas Belon wrote:
> And considering also there might be other yet unknown bugs because of gcc4, it
> is most likely better to stick to use gcc-3.x, unless there is really no other
> option.
>
> For cases where no compat-gcc package is provided (like in OpenSUSE) then the
> followin
If I stop KVM in the monitor with "stop", wait a minute, and do
"cont", a Linux guest gives me a "BUG: soft lockup detected on CPU#0".
Is that expected behavior? What isn't virtualized that allows it to
detect that? The host is a core 2 duo.
I have bigger problems in the guest after migrating to
Avi Kivity wrote:
> Jim Paris wrote:
> > If I stop KVM in the monitor with "stop", wait a minute, and do
> > "cont", a Linux guest gives me a "BUG: soft lockup detected on CPU#0".
> > Is that expected behavior?
>
> No.
>
> > W
Joris wrote:
> I have a Debian unstable 64bit host on an intel S3000 quad core xeon
> X3210. Kernel 2.6.22-2-amd64 (debian flavour) KVM46.
> My guests are debian32 with 1 cpu and 1GB ram, connected via '-net
> nic,macaddr=52:54:00:00:00:xx -net tap' and linux bridging. I'm
> running 3 guests at the
Joris wrote:
> Both changing the nic (to rtl8139) and rebooting the host solved the
> issue for me.
> My VM's have now survived over 12 hours of intense activity without a glitch.
>
> To be clear: soly changing the nic without rebooting the host worked;
> after rebooting the host the default nic w
Peter Osuchowski wrote:
> talithaA ~ # ping 10.0.1.1
> PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data.
> 64 bytes from 10.0.1.1: icmp_seq=1 ttl=64 time=850 ms
> 64 bytes from 10.0.1.1: icmp_seq=2 ttl=64 time=389 ms
> 64 bytes from 10.0.1.1: icmp_seq=3 ttl=64 time=0.353 ms
> 64 bytes from 10.0.1.1: i
Hi,
> - add file:// migration protocol (Uri Lublin)
commit 70d2a9dc3594446f3ad66b32abc94c08b74118d4
Author: Uri Lublin <[EMAIL PROTECTED]>
Date: Thu Feb 21 15:00:50 2008 +0200
kvm: qemu: migration: added file:// migration protocol
Instead of writing into a file with fork+exec, jus
David Abrahams wrote:
> > What HAL do you see in device manager?
>
> In the guest? I don't see anything that obviously appears to be HAL in
> device manager. Could you be more specific?
Hi,
He's referring to the Windows computer type -- the entry under
"computer" in device manager. See
http
26 matches
Mail list logo
