Paolo Bonzini pbonz...@redhat.com wrote:
Il 11/09/2014 19:03, Chris Webb ha scritto:
Paolo Bonzini pbonz...@redhat.com wrote:
This is a hypercall that should have kicked VCPU 3 (see rcx).
Can you please apply this patch and gather a trace of the host
(using trace-cmd -e kvm qemu-kvm
Paolo Bonzini pbonz...@redhat.com wrote:
This is a hypercall that should have kicked VCPU 3 (see rcx).
Can you please apply this patch and gather a trace of the host
(using trace-cmd -e kvm qemu-kvm arguments)?
Sure, no problem. I've built the trace-cmd tool against udis86 (I hope) and
have
I've reported this bug before, which reliably crashes a guest kernel shortly
after boot, but have just reconfirmed that it is still present with Linux
3.16.2 guest and host kernels and Qemu 2.1.
Running a 3.16.2 x86-64 SMP guest kernel on qemu-2.1, with kvm enabled and
-cpu host on a 3.16.2 AMD
I see kernel 3.15 is now out, so I retested with 3.15 guest and host. I'm
still getting exactly the same guest kernel panic: a divide error in
kvm_unlock_kick with -cpu host, but not with -cpu qemu64:
divide error: [#1] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 781 Comm: mkdir Not tainted
Running a 3.14.4 x86-64 SMP guest kernel on qemu-2.0, with kvm enabled and
-cpu host on a 3.14.4 AMD Opteron host, I'm seeing a reliable kernel panic from
the guest shortly after boot. I think is happening in kvm_unlock_kick() in the
guest kernel paravirt_ops code:
divide error: [#1] PREEMPT
Eric Van Hensbergen eri...@gmail.com writes:
A passthrough makes perfect sense, a couple summers ago we had an
Extreme Blue team working on using 9p for a cloud hosting environment
-- while they were primarily working on gatewaying through a host
operating system we also discussed doing 9p
We're planning to implement shared filesystems for guests on our virtualized
hosting platform, stored on a central fileserver separate from the hosts.
Whilst we can mount the shares on each host and then use qemu's 9p
passthrough/proxy support to access the mountpoint, going via the host
kernel
Chris Webb ch...@arachsys.com writes:
I'm experiencing a problem with qemu + macvtap which I can reproduce on a
variety of hardware, with kernels varying from 3.0.4 (the oldest I tried) to
3.5.1 and with qemu[-kvm] versions 0.14.1, 1.0, and 1.1.
Large data transfers over TCP into a guest
I'm experiencing a problem with qemu + macvtap which I can reproduce on a
variety of hardware, with kernels varying from 3.0.4 (the oldest I tried) to
3.5.1 and with qemu[-kvm] versions 0.14.1, 1.0, and 1.1.
Large data transfers over TCP into a guest from another machine on the
network are very
Michael S. Tsirkin m...@redhat.com writes:
On Thu, Aug 16, 2012 at 10:20:05AM +0100, Chris Webb wrote:
For example, I can run
ip addr add 192.168.1.2/24 dev eth0
ip link set eth0 up
ip link add link eth0 name tap0 address 02:02:02:02:02:02 type macvtap
mode bridge
ip
Hi. Sorry for the slow follow-up.
Stefan Hajnoczi stefa...@gmail.com writes:
Yes, it's odd that QEMU changes make the issue go away but tcpdump
suggests the packet is not being sent from the bridge to the tap
device.
Indeed. I really don't understand how to the two could possible interact!
Stefan Hajnoczi stefa...@gmail.com writes:
On Tue, Apr 3, 2012 at 5:37 PM, Chris Webb ch...@arachsys.com wrote:
Stefan Hajnoczi stefa...@gmail.com writes:
Are you sure no other guest has the same MAC address or IP address?
This weird behavior sounds similar to what happens when you
When I first started setting up qemu-kvm VMs for customers, I set up their
internet-facing network with tap interfaces enslaved to a host bridge along
with the physical network card of the host, something like
ip tuntap add dev tapN mode tap
brctl addif br0 tapN
ip link set tapN up
Stefan Hajnoczi stefa...@gmail.com writes:
On Mon, Apr 02, 2012 at 04:37:23PM +0100, Chris Webb wrote:
We initially saw a problem after an upgrade from 0.15.x to 1.0.
Perhaps git-bisect(1) can help you track down the change that introduced
this between 0.15 and 1.0.
Hi. I attempted
Stefan Hajnoczi stefa...@gmail.com writes:
In a case like this it might be most effective to catch a VM in the
bad state and then go in with gdb to see what is broken. The basic
approach would be putting breakpoints on the e1000 device model's
transmit/receive paths to see if the guest is
Stefan Hajnoczi stefa...@gmail.com writes:
No, that's weird. I would have simply tried b start_xmit and as
long as the binary has symbols gdb would know what to do.
I'll get another one and give it a go. There wasn't any particular reason I
gave a line number rather than a function except
Stefan Hajnoczi stefa...@gmail.com writes:
Are you sure no other guest has the same MAC address or IP address?
This weird behavior sounds similar to what happens when you have
multiple devices on a network using the same address - the results are
very confusing :).
Yes, I agree!
I have an interesting bug with the e1000 emulation in qemu-kvm 1.0. I've
spent a bit of time trying to track it down, but the behaviour is
sufficiently odd that I'm rather baffled.
The public networking on our VMs consists of a bridge to which the physical
nic is enslaved, a tap interface created
Stefan Hajnoczi stefa...@linux.vnet.ibm.com writes:
Chris and Richard: Please test this to confirm that it fixes the hang you
reported.
We've been testing this (v1 against qemu-kvm 1.0) today, and it's looking
very good. Thanks!
The lock-ups during boot no longer happen, and if you severely
Stefan Hajnoczi stefa...@gmail.com writes:
Thanks for trying it out.
Regarding the guest kernel errors, they may be timeouts. The guest
may consider the IDE controller buggy/dead due to how long requests
take to complete under severe throttling. There's not much that can
be done about
Stefan Hajnoczi stefa...@linux.vnet.ibm.com writes:
The second aim of this conversion is to avoid calling bdrv_read()/bdrv_write()
since they do not work with I/O throttling. This means guests should now boot
IDE drives successfully when I/O throttling is enabled.
[...]
Chris and Richard:
Stefan Hajnoczi stefa...@linux.vnet.ibm.com writes:
On Thu, Mar 22, 2012 at 07:07:52PM +, Chris Webb wrote:
Stefan Hajnoczi stefa...@linux.vnet.ibm.com writes:
Yesterday I only posted an analysis of the bug but here are some
thoughts on how to move forward. Throttling itself
Stefan Hajnoczi stefa...@linux.vnet.ibm.com writes:
Yesterday I only posted an analysis of the bug but here are some
thoughts on how to move forward. Throttling itself is not the problem.
We've known that synchronous operations in the vcpu thread are a problem
long before throttling. This
Whilst you have patches in progress for the queue draining issue with the IO
throttling code which triggers the assert()s in the ide driver, I thought I
should report a second bug I've seen. I'm not sure whether it's related, but
none of the patch series posted so far appear to fix or affect it.
Zhi Yong Wu zwu.ker...@gmail.com writes:
On Mon, Feb 20, 2012 at 5:18 AM, Chris Webb ch...@arachsys.com wrote:
I would indeed quite like to backport this to qemu 1.0! Am I right in
thinking the sanest way to do this is to apply 922453bca6a9 to bring all the
relevant qemu_aio_flush() calls
zwu.ker...@gmail.com writes:
The patch is based on the latest QEMU upstream. If you will backport the
patchset to QEMU 1.0, pls note the difference.
I would indeed quite like to backport this to qemu 1.0! Am I right in
thinking the sanest way to do this is to apply 922453bca6a9 to bring all
We run a cloud hosting provider using qemu-kvm 1.0, and are keen to find a
contractor to track down and fix some issues with blockio throttled IDE
devices in current qemu HEAD.
The impact of a heavy user of disk IO on other virtual machines' disk
performance is a real and serious problem for us,
Possible a stupid question, but noting the new AHCI support in qemu, how do
I specify an AHCI drive to attach to a qemu VM?
I can create IDE, SCSI and virtio drives with
-drive if=ide,bus=M,unit=N,...
-drive if=scsi,bus=M,unit=N,...
-drive if=virtio,index=N,...
but when I attempted to
Thanks for the swift reply!
Daniel P. Berrange berra...@redhat.com writes:
Using -drive with an if=XXX which is anything other than 'none' is the
deprecated / legacy syntax. The way libvirt does AHCI is to use the more
verbose/modern syntax:
-device ahci,id=ahci0
-drive
/root,...
Signed-off-by: Chris Webb ch...@arachsys.com
---
qemu-options.hx |4 ++--
vl.c| 16 +++-
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 681eaf1..865e3a2 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
change_process_uid() checks that privileges have been successfully dropped by
verifying that setuid(0) fails. However, if qemu is explicitly -runas root,
the setuid(0) would correctly succeed, so we skip the test in that case.
Signed-off-by: Chris Webb ch...@arachsys.com
---
os-posix.c |2
This allows qemu to drop privileges to a dynamically allocated, anonymous UID
and GID without needing a temporary /etc/passwd entry for that UID. The
UID:GID format is very standard, being (for example) the syntax used by
chown(1) for numeric IDs.
Signed-off-by: Chris Webb ch...@arachsys.com
Avi Kivity a...@redhat.com writes:
On 11/24/2011 06:29 PM, Chris Webb wrote:
This allows qemu to drop privileges to a dynamically allocated, anonymous
UID
and GID without needing a temporary /etc/passwd entry for that UID. The
UID:GID format is very standard, being (for example
change_process_uid() checks that privileges have been successfully dropped by
verifying that setuid(0) fails. However, if qemu is explicitly -runas root,
the setuid(0) would correctly succeed, so we skip the test in that case.
Signed-off-by: Chris Webb ch...@arachsys.com
---
os-posix.c |2
This allows qemu to drop privileges to a dynamically allocated, anonymous UID
and GID without needing a temporary /etc/passwd entry for that UID. The
UID:GID format is very standard, being (for example) the syntax used by
chown(1) for numeric IDs.
Signed-off-by: Chris Webb ch...@arachsys.com
/root,...
Signed-off-by: Chris Webb ch...@arachsys.com
---
qemu-options.hx |4 ++--
vl.c| 16 +++-
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 681eaf1..865e3a2 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
Peter Maydell peter.mayd...@linaro.org writes:
On 24 November 2011 16:04, Chris Webb ch...@arachsys.com wrote:
+ ?? ?? ?? ?? ?? ?? ?? ??if (qemu_opts_id(opts)) {
+ ?? ?? ?? ?? ?? ?? ?? ?? ??fsdev =
qemu_opts_create(qemu_find_opts(fsdev
I have a qemu-kvm guest (apparently a Ubuntu 11.04 x86-64 install) which has
stopped and refuses to continue:
(qemu) info status
VM status: paused
(qemu) cont
(qemu) info status
VM status: paused
The host is running linux 2.6.39.2 with qemu-kvm 0.14.1 on 24-core Opteron
6176 box, and
Kevin Wolf kw...@redhat.com writes:
Am 24.10.2011 12:00, schrieb Chris Webb:
I have qemu monitor access and can even strace the relevant qemu process if
necessary: is it possible to use this to diagnose what's caused this guest
to stop, e.g. the unsupported instruction if it's an emulation
Kevin Wolf kw...@redhat.com writes:
In qemu 1.0 we'll have an extended 'info status' that includes the stop
reason, but 0.14 doesn't have this yet (was committed to git master only
recently).
Right, okay. I might take a look at cherry-picking and back-porting that to
our version of qemu-kvm
Kevin Wolf kw...@redhat.com writes:
Good point... The only other thing that I can think of would be
attaching gdb and setting a breakpoint in vm_stop() or something.
Perfect, that seems to identified what's going on very nicely:
(gdb) break vm_stop
Breakpoint 1 at 0x407d10: file
Chris Webb ch...@arachsys.com writes:
I'm trying to get bridge-mode communication between a macvtap and a host
macvlan working correctly, but I think I must be doing something wrong as
the host macvlan and guest macvtap apparently can't communicate. I'm aware
that the underlying eth0
I'm trying to get bridge-mode communication between a macvtap and a host
macvlan working correctly, but I think I must be doing something wrong as
the host macvlan and guest macvtap apparently can't communicate. I'm aware
that the underlying eth0 interface can't communicate with the macvtap, but I
cc39a92cbfc8 fixed a SIGFPE where the screen is resized to width/hight 1 and
then receives a mouse click. However, there is a still a tiny window here for
a race between the test for width/height 1 and the division.
Signed-off-by: Chris Webb ch...@arachsys.com
---
Sending this as I've just seen
cc39a92cbfc8 fixed a SIGFPE where the screen is resized to width/hight 1 and
then receives a mouse click. However, there is a still a tiny window here for
a race between the test for width/height 1 and the division.
Signed-off-by: Chris Webb ch...@arachsys.com
---
Sending this as I've just seen
Markus Armbruster arm...@redhat.com writes:
Michael S. Tsirkin m...@redhat.com writes:
Everyone ok with disabling vlans with no config option?
Wrong question. You got to ask anyone *not* ok with disabling vlans
with no config option?
We do use socket devices in the form
-net
Avi Kivity a...@redhat.com writes:
On 03/02/2010 11:34 AM, Jernej Simončič wrote:
On Tuesday, March 2, 2010, 9:21:18, Chris Webb 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
I tried to grab a recursive clone of qemu.git in order to get the head of
the seabios and vgabios trees to match the head of qemu.git, but the
operation failed with
$ git clone --recursive git://git.qemu.org/qemu.git qemu-r
Initialized empty Git repository in /home/chris/git/qemu-r/.git/
During boot, the screen gets resized to height 1 and a mouse click at this
point will cause a division by zero when calculating the absolute pointer
position from the pixel (x, y). Return a click in the middle of the screen
instead in this case.
Signed-off-by: Chris Webb ch...@arachsys.com
Alexander Graf ag...@suse.de writes:
On 05.03.2010, at 17:52, Chris Webb wrote:
Of course, if the screen width or height is 1, it doesn't really matter what
the value of the mouse position for the click is, so something as simple as
diff --git a/vnc.c b/vnc.c
--- a/vnc.c
+++ b
We've just seen another VNC related qemu-kvm crash, this time an arithmetic
exception at vnc.c:1424 in the newly release qemu-kvm 0.12.3.
[...]
1423 if (vs-absolute) {
1424 kbd_mouse_event(x * 0x7FFF / (ds_get_width(vs-ds) - 1),
1425 y * 0x7FFF /
Avi Kivity a...@redhat.com writes:
On 02/21/2010 07:23 PM, Chris Webb wrote:
Some sort of race where a client disconnects and is removed from the client
list while the vnc_refresh() loop is iterating over it, maybe?
Looks like c727a05459, and high time for 0.12.3. Anthony?
Ah yes, looks
I've just had a segfault from one of the qemu-kvm virtual machines we run.
This is qemu-kvm 0.12.2 running with the in-kernel kvm modules on linux
2.6.32.7 on a dual quad-core Xeon E5420 machine, with ksm enabled.
The backtrace looks like
#0 vnc_update_client (vs=0x83f0, has_dirty=18) at
Hi. There's a connected discussion on the sheepdog list about locking, and I
have a patch there which could complement this one quite well.
Sheepdog is a distributed, replicated block store being developed
(primarily) for Qemu. Images have a mandatory exclusive locking requirement,
enforced by
Anthony Liguori anth...@codemonkey.ws writes:
I've resisted this because I'm concerned that if we delay the
opening of the file on the destination, it could fail. That's a
very late failure and that makes me uncomfortable as just a work
around for NFS.
I don't know much about NFS's
Daniel P. Berrange berra...@redhat.com writes:
The only other alternative would be for the destination to open the disks,
but not immediately acquire the locks. In the final stage of migration have
the source release its lock signal to the dest that it can now acquire
the lock. The
MORITA Kazutaka morita.kazut...@lab.ntt.co.jp writes:
We use JGroups (Java library) for reliable multicast communication in
our cluster manager daemon. We don't worry about the performance much
since the cluster manager daemon is not involved in the I/O path. We
might think about moving to
Javier Guerra jav...@guerrag.com writes:
i'd just want to add my '+1 votes' on both getting rid of JVM
dependency and using block devices (usually LVM) instead of ext3/btrfs
If the chunks into which the virtual drives are split are quite small (say
the 64MB used by Hadoop), LVM may be a less
58 matches
Mail list logo
