Am 12.11.2011 08:26, schrieb Stefan Weil:
> Am 12.11.2011 03:05, schrieb Andreas Färber:
>> On current qemu.git master for qemu-system-x86_64 I observe crashes
>> similar to this one when running info mtree on the SDL monitor console:
>>
>> *** glibc detected ***
>> /home/andreas/QEMU/qemu-rl78/rl7
Am 10.11.2011 12:29, schrieb Andreas Färber:
> Am 10.11.2011 11:32, schrieb Alexander Graf:
>>
>> On 10.11.2011, at 10:53, Andreas Färber wrote:
>>
>>> Is there a known issue with running multiple instances of
>>> qemu-system-s390x? I got a hang on openSUSE 12.1 RC2 x86_64 host:
>>>
>>> 0x7f0d
On 11/10/2011 07:54 PM, Anthony Liguori wrote:
>> IMO, this should be a release blocker. qemu 1.0 only supporting
>> migration on enterprise storage?
>
>
> No, this is not going to block the release.
>
> You can't dump patches on the ML during -rc for an issue that has been
> understood for well o
On 11/11/2011 12:15 PM, Kevin Wolf wrote:
> Am 10.11.2011 22:30, schrieb Anthony Liguori:
> > Live migration with qcow2 or any other image format is just not going to
> > work
> > right now even with proper clustered storage. I think doing a block level
> > flush
> > cache interface and lettin
On 11/11/2011 04:03 PM, Anthony Liguori wrote:
>
> I don't view not supporting migration with image formats as a
> regression as it's never been a feature we've supported. While there
> might be confusion about support around NFS, I think it's always been
> clear that image formats cannot be used.
Hi, Stefan
> Thanks, I have added your mascots to my icon / mascot collection
> (http://qemu.weilnetz.de/icon/), also in different standard sizes.
>
> There is still a lot of unused space around the image, therefore scaling
> of the svg file does not look pretty. By fixing the document properties
Am 12.11.2011 11:08, schrieb Andreas Färber:
Am 10.11.2011 12:29, schrieb Andreas Färber:
I found that the following main-loop change works around it for s390x
and rl78 but breaks x86_64 SeaBIOS boot. Paolo, any ideas?
diff --git a/main-loop.c b/main-loop.c
index 60e9748..2ab5023 100644
--- a/ma
Am 12.11.2011 11:27, schrieb 陳韋任:
Hope this what you want,
http://people.cs.nctu.edu.tw/~chenwj/slide/QEMU/QEMU_Mascot_no_text.svg
http://people.cs.nctu.edu.tw/~chenwj/slide/QEMU/QEMU_Mascot_embody_text.svg
http://people.cs.nctu.edu.tw/~chenwj/slide/QEMU/QEMU_Mascot_text_right.svg
R
> Which character fonts did you use for 'Q' and for 'emu'
> in QEMU_Mascot_embody_text.svg?
Andalus for 'Q' and Berlin Sans FB for 'emu'.
> It might be interesting to try 'emu' rotated by about -60 degree
> (in the direction of the egg shaped body).
This direction?
http://people.cs.nctu.
On 12.11.2011, at 11:40, Stefan Weil wrote:
> Am 12.11.2011 11:08, schrieb Andreas Färber:
>> Am 10.11.2011 12:29, schrieb Andreas Färber:
>> I found that the following main-loop change works around it for s390x
>> and rl78 but breaks x86_64 SeaBIOS boot. Paolo, any ideas?
>>
>> diff --git a/ma
On 11/12/2011 04:20 AM, Avi Kivity wrote:
On 11/10/2011 07:54 PM, Anthony Liguori wrote:
IMO, this should be a release blocker. qemu 1.0 only supporting
migration on enterprise storage?
No, this is not going to block the release.
You can't dump patches on the ML during -rc for an issue that
On 11/12/2011 04:27 AM, Avi Kivity wrote:
On 11/11/2011 04:03 PM, Anthony Liguori wrote:
I don't view not supporting migration with image formats as a
regression as it's never been a feature we've supported. While there
might be confusion about support around NFS, I think it's always been
clea
Am 12.11.2011 12:37, schrieb 陳韋任:
Which character fonts did you use for 'Q' and for 'emu'
in QEMU_Mascot_embody_text.svg?
Andalus for 'Q' and Berlin Sans FB for 'emu'.
It might be interesting to try 'emu' rotated by about -60 degree
(in the direction of the egg shaped body).
This direction?
On 11/12/2011 03:39 PM, Anthony Liguori wrote:
> On 11/12/2011 04:27 AM, Avi Kivity wrote:
>> On 11/11/2011 04:03 PM, Anthony Liguori wrote:
>>>
>>> I don't view not supporting migration with image formats as a
>>> regression as it's never been a feature we've supported. While there
>>> might be c
On 11/12/2011 03:30 PM, Anthony Liguori wrote:
>> Nor can you yank support for migration this way. Might as well put a
>> big sign on 1.0, "Do Not Use This Release".
>
>
> You're joking, right?
No.
>
> Let's be very clear. Live migration works perfectly fine when you use
> raw images and cohere
This lets different subsystems register an Error that is thrown whenever
migration is attempted. This works nicely because it gracefully supports
things like hotplug.
Right now, if multiple errors are registered, only one of them is reported.
I expect that for 1.1, we'll extend query-migrate to r
Now when you try to migrate with ivshmem, you get a proper QMP error:
(qemu) migrate tcp:localhost:1025
Migration is disabled when using feature 'peer mode' in device 'ivshmem'
(qemu)
Signed-off-by: Anthony Liguori
---
hw/ivshmem.c | 12 +++-
qerror.c |4
qerror.h |
Image files have two types of data: immutable data that describes things like
image size, backing files, etc. and mutable data that includes offset and
reference count tables.
Today, image formats aggressively cache mutable data to improve performance. In
some cases, this happens before a guest e
On 11/12/2011 08:43 AM, Avi Kivity wrote:
On 11/12/2011 03:39 PM, Anthony Liguori wrote:
On 11/12/2011 04:27 AM, Avi Kivity wrote:
On 11/11/2011 04:03 PM, Anthony Liguori wrote:
I don't view not supporting migration with image formats as a
regression as it's never been a feature we've support
Now when you try to migrate with qed, you get:
(qemu) migrate tcp:localhost:1025
Block format 'qed' used by device 'ide0-hd0' does not support feature 'live
migration'
(qemu)
Signed-off-by: Anthony Liguori
---
block/qed.c | 10 ++
block/qed.h |2 ++
2 files changed, 12 insertions
I think this is an accurate reflection of the state of migration today. This
is the second release in a row where we're scrambling to fix a critical issue
in migration.
The first step in fixing this problem is being up front about what the current
state of the subsystem is. If we're going to tre
Now when you try to migrate with qcow2, you get:
(qemu) migrate tcp:localhost:1025
Block format 'qcow2' used by device 'ide0-hd0' does not support feature 'live
migration'
(qemu)
Signed-off-by: Anthony Liguori
---
block/qcow2.c |9 +
block/qcow2.h |2 ++
qemu-tool.c |9 ++
Now when you try to migrate with qed, you get:
(qemu) migrate tcp:localhost:1025
Block format 'qed' used by device 'ide0-hd0' does not support feature 'live
migration'
(qemu)
Signed-off-by: Anthony Liguori
---
block/qed.c | 10 ++
block/qed.h |2 ++
2 files changed, 12 insertions
Only block migration if we're using encrypted files.
Signed-off-by: Anthony Liguori
---
block/qcow2.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index b5171e0..8071f2c 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -2
This lets different subsystems register an Error that is thrown whenever
migration is attempted. This works nicely because it gracefully supports
things like hotplug.
Right now, if multiple errors are registered, only one of them is reported.
I expect that for 1.1, we'll extend query-migrate to r
We don't reopen the actual file, but instead invoke the close and open routines.
We specifically ignore the backing file since it's contents are read-only and
therefore immutable.
Signed-off-by: Anthony Liguori
---
block/qcow2.c | 19 +++
block/qcow2.h |2 ++
2 files change
We don't reopen the actual file, but instead invoke the close and open routines.
We specifically ignore the backing file since it's contents are read-only and
therefore immutable.
Signed-off-by: Anthony Liguori
---
block/qcow2.c | 19 +++
block/qcow2.h |2 ++
2 files change
Now when you try to migrate with ivshmem, you get a proper QMP error:
(qemu) migrate tcp:localhost:1025
Migration is disabled when using feature 'peer mode' in device 'ivshmem'
(qemu)
Signed-off-by: Anthony Liguori
---
hw/ivshmem.c | 12 +++-
qerror.c |4
qerror.h |
Now when you try to migrate with qcow2, you get:
(qemu) migrate tcp:localhost:1025
Block format 'qcow2' used by device 'ide0-hd0' does not support feature 'live
migration'
(qemu)
Signed-off-by: Anthony Liguori
---
block/qcow2.c |9 +
block/qcow2.h |2 ++
qemu-tool.c |9 ++
Only block migration if we're using encrypted files.
Signed-off-by: Anthony Liguori
---
block/qcow2.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index b5171e0..8071f2c 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -2
On Fri, Nov 11, 2011 at 03:27:59PM +0800, Cao,Bing Bu wrote:
> Hi,
>
> I have post a HOWTO document about windows guest debugging on:
> http://www.linux-kvm.org/page/WindowsGuestDrivers/UpdatedGuestDebugging
>
The first DriverUnload should be DriverLoad, right?
Otherwise great idea.
>
Image files have two types of data: immutable data that describes things like
image size, backing files, etc. and mutable data that includes offset and
reference count tables.
Today, image formats aggressively cache mutable data to improve performance. In
some cases, this happens before a guest e
On Fri, 11 Nov 2011 14:29:36 -0600, Anthony Liguori wrote:
> Now when you try to migrate with ivshmem, you get a proper QMP error:
>
> (qemu) migrate tcp:localhost:1025
> Migration is disabled when using feature 'peer mode' in device 'ivshmem'
> (qemu)
>
We may want to add a similar one when us
- This mail is a HTML mail. Not all elements could be shown in plain text
mode. -
Hi,
Visit my site
http://fmcgfactsonline.com
Regards ...
FMCG TEAM
On Fri, Nov 11, 2011 at 5:10 PM, Kevin Wolf wrote:
> Am 11.11.2011 05:06, schrieb Zhi Yong Wu:
>> On Fri, Nov 11, 2011 at 1:32 AM, Kevin Wolf wrote:
>>> qcow2 has a writeback metadata cache, so flushing a qcow2 image actually
>>> consists of writing back that cache to the protocol and only then f
With -icount, the vm_clock is updated with help from TCG (it counts
instructions at 2^ICOUNT ns/instructions). With KVM, the instruction count is
not available so KVM cannot provide this help.
Signed-off-by: Cao,Bing Bu
---
vl.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(
36 matches
Mail list logo
