Paolo Bonzini wrote:
> Il 11/09/2014 19:03, Chris Webb ha scritto:
>> Paolo Bonzini 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
>>> (u
Paolo Bonzini 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 ")?
Sure, no problem. I've built the trace-cmd tool against udis86 (I hope) and
have put the resulting trac
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 Op
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 3
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 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 passthrough (pr
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 an
Chris Webb 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
"Michael S. Tsirkin" 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:0
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 sl
Hi. Sorry for the slow follow-up.
Stefan Hajnoczi 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!
> e1000 and rtl8
Stefan Hajnoczi writes:
> On Tue, Apr 3, 2012 at 5:37 PM, Chris Webb wrote:
> > Stefan Hajnoczi writes:
> >
> >
> >> >> Are you sure no other guest has the same MAC address or IP address?
> >> >> This weird behavior sounds similar to what
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
qemu-kv
Stefan Hajnoczi 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! However
Stefan Hajnoczi 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 that I worried the
Stefan Hajnoczi 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 giving us packets
Stefan Hajnoczi 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
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 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 that, I think.
Stefan Hajnoczi 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 throttle
(1MB/s, 100 req/s)
Stefan Hajnoczi 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: Please test this to confir
Stefan Hajnoczi writes:
> On Thu, Mar 22, 2012 at 07:07:52PM +0000, Chris Webb wrote:
> > Stefan Hajnoczi writes:
> >
> > > Yesterday I only posted an analysis of the bug but here are some
> > > thoughts on how to move forward. Throttling itself is not th
Stefan Hajnoczi 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 is just another reason to
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.
I
Zhi Yong Wu writes:
> On Mon, Feb 20, 2012 at 5:18 AM, Chris Webb 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 through th
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 t
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, a
Thanks for the swift reply!
"Daniel P. Berrange" 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
> if=none,file=/var
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 test
Peter Maydell writes:
> On 24 November 2011 16:04, Chris Webb wrote:
> > + ?? ?? ?? ?? ?? ?? ?? ??if (qemu_opts_id(opts)) {
> > + ?? ?? ?? ?? ?? ?? ?? ?? ??fsdev =
> > qemu_opts_create(
local,id=root,path=/path/to/rootfs,mount_tag=/dev/root,...
Signed-off-by: Chris Webb
---
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
---
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
---
os-posix.c | 16
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
---
os-posix.c |2 +-
1 files changed
Avi Kivity 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, bei
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
---
os-posix.c | 16
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
---
os-posix.c |2 +-
1 files changed
local,id=root,path=/path/to/rootfs,mount_tag=/dev/root,...
Signed-off-by: Chris Webb
---
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
---
Kevin Wolf 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 /home/root/packages/qemu-kvm
Kevin Wolf 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 if it's not too
Kevin Wolf 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
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 ha
Chris Webb 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 unde
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
---
Sending this as I've just seen a SIGFPE
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
---
Sending this as I've just seen a SIGFPE
Markus Armbruster writes:
> "Michael S. Tsirkin" 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 nic,model=e1000,vlan=X,mac=MM
Avi Kivity 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
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/
rem
Chris Webb writes:
> 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.
I think t
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
---
vnc.c |6
Alexander Graf 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.
Anthony Liguori writes:
> On 03/01/2010 12:14 PM, Chris Webb wrote:
> >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.
> >
> > [...]
> > 1
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 / (ds_
Avi Kivity 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
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 vnc.c
"Daniel P. Berrange" 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 assumption being that
Anthony Liguori 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 semantics with cache-coher
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 the
Javier Guerra 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 appropriate choice
Chris Webb writes:
> MORITA Kazutaka 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 p
MORITA Kazutaka 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 corosync if it is more stabl
61 matches
Mail list logo
