Return a QDict, which may contain another QDict if the migration
process is active.
IMPORTANT: as a QInt stores a int64_t integer, RAM values are going
to be stored as int64_t and not as uint64_t as they are today. If
this is a problem QInt will have to be changed.
This commit should not change u
Each block device information is stored in a QDict and the
returned QObject is a QList of all devices.
This commit should not change user output.
Signed-off-by: Luiz Capitulino
---
Makefile |6 +-
block.c | 123 +++--
block.h |
Each device is represented by a QDict. The returned QObject is a QList
of all devices.
This commit should not change user output.
Signed-off-by: Luiz Capitulino
---
monitor.c |3 ++-
qemu-char.c | 43 +--
qemu-char.h |4 +++-
3 files changed,
Each device statistic information is stored in a QDict and
the returned QObject is a QList of all devices.
This commit should not change user output.
Signed-off-by: Luiz Capitulino
---
block.c | 82
block.h |3 +-
monitor.c
Return a QDict with information about the just added device.
This commit should not change user output.
Please, note that this patch does not do error handling
conversion. In error conditions the handler still calls
monitor_printf().
Signed-off-by: Luiz Capitulino
---
hw/pci-hotplug.c | 40 +
Return a QDict with server information. Connected clients are returned
as a QList of QDicts.
The new functions (vnc_qdict_remote_addr(), vnc_qdict_local_addr() and
put_addr_qdict()) are used to insert 'host' and 'service' information
in the returned QDict.
This patch is big, but I don't see how t
On 11/23/2009 02:52 AM, Gerd Hoffmann wrote:
>
> All not needed. Simply registering as qdev device is enougth. You can
> then add a debug port like this, without adding new cmd line options:
>
>-chardev vc,id=debug -device isa-debugcon,chardev=debug
>
> Adding a second one on a non-defaul
On Fri, Nov 20, 2009 at 12:34:29PM +0100, Alexander Graf wrote:
> ag...@busu:~/work/qemu-late-int19/qemu> ./x86_64-softmmu/qemu-system-
> x86_64 -nographic -kernel ../bzImage -append console=ttyS0 -L pc-bios -
> enable-kvm
> [0.00] Linux version 2.6.32-rc7 (h...@brick) (gcc version 4.3.4
Excerpts from Anthony Liguori's message of Mon Nov 23 14:44:04 -0200 2009:
>
> I don't want to transparently migrate from 5.4.1 to 5.4.0 and have my
> guest's time start drifting. I specifically want that to fail.
If you migrate from 5.4.0 to 5.4.0 or from 5.4.0 to 5.4.1, the guest
will also st
This patchset adds MIPS16 support to the MIPS backend. MIPS16 is a
compact encoding of a subset of the MIPS integer instructions, similar
to ARM's Thumb mode. The processor enters MIPS16 mode by executing a
special jump instruction; execution continus at the jump target in
MIPS16 mode until the p
It's easier to implement mips16 shift instructions if we're not
examining the opcode inside gen_shift_{imm,}. So move ROTR and ROTRV
and do the special-case handling of SRL and SRLV inside decode_opc.
Likewise for their 64-bit counterparts.
Signed-off-by: Nathan Froyd
---
target-mips/translate.
There's no good way to add this incrementally, so we do it all at once.
The only changes to shared code are in handle_delay_slot. We need to
flip ISAMode when doing a jump-and-exchange. We also need to set
ISAMode the low bit of the target address for jump-to-register.
Signed-off-by: Nathan Froy
Signed-off-by: Nathan Froyd
---
target-mips/helper.c| 47 ++-
target-mips/op_helper.c | 10 +++---
2 files changed, 33 insertions(+), 24 deletions(-)
diff --git a/target-mips/helper.c b/target-mips/helper.c
index 4a37277..e54a31a 100644
--
Move delay slot handling to common code whose invocation can be
controlled from gen_intermediate_code_internal.
Signed-off-by: Nathan Froyd
---
target-mips/translate.c | 134 +++---
1 files changed, 79 insertions(+), 55 deletions(-)
diff --git a/target-m
Signed-off-by: Nathan Froyd
---
target-mips/cpu.h |1 +
target-mips/translate.c |2 ++
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/target-mips/cpu.h b/target-mips/cpu.h
index 82f9a38..e8febe6 100644
--- a/target-mips/cpu.h
+++ b/target-mips/cpu.h
@@ -167,6 +167,7
We create separate masks for the "basic" branch hflags and the
"extended" branch hflags and define MIPS_HFLAG_BMASK as the logical or
of those two. This is done to avoid churning the codebase in lots of
different places.
Signed-off-by: Nathan Froyd
---
target-mips/cpu.h |8 +++-
1 files
This is a common pattern in existing code. We'll also use it to
implement the mips16 SAVE/RESTORE instructions.
Signed-off-by: Nathan Froyd
---
target-mips/translate.c | 40
1 files changed, 16 insertions(+), 24 deletions(-)
diff --git a/target-mips/t
Signed-off-by: Nathan Froyd
---
target-mips/translate.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index 49d2264..ef5e726 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -4,6 +4,7 @@
* Copyri
Signed-off-by: Nathan Froyd
---
target-mips/translate.c | 112 +++
1 files changed, 112 insertions(+), 0 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index e7aee33..611774b 100644
--- a/target-mips/translate.c
+++ b/tar
On Mon, Nov 23, 2009 at 01:49:09PM -0600, Anthony Liguori wrote:
> Eduardo Habkost wrote:
>> On Mon, Nov 23, 2009 at 12:28:16PM -0600, Anthony Liguori wrote:
>>> After mulling over it a bit, here's what I'd suggest:
>>>
>>> 1) Integrate VMstate with qdev
>>> 2) Introduce a bitmap bla
Am 23.11.2009 um 21:21 schrieb Christoph Hellwig :
On Fri, Nov 20, 2009 at 12:34:29PM +0100, Alexander Graf wrote:
ag...@busu:~/work/qemu-late-int19/qemu> ./x86_64-softmmu/qemu-system-
x86_64 -nographic -kernel ../bzImage -append console=ttyS0 -L pc-
bios -
enable-kvm
[0.00] Linux ve
Gleb Natapov wrote:
On Mon, Nov 23, 2009 at 08:19:54PM +0100, Sebastian Herbszt wrote:
Gleb Natapov wrote:
>On Sun, Nov 22, 2009 at 09:01:45PM +0100, Sebastian Herbszt wrote:
>>Gleb Natapov wrote:
>>>On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote:
Bad things could hap
On Mon, Nov 23, 2009 at 10:28:44PM +0100, Alexander Graf wrote:
> >Is this on an x86_64 box or i386? I can boot the same kernel with
> >upstream qemu on another box with an x86_64 kernel and qemu.
>
> I only test things on x86_64. so you're saying it breaks on an i586
> host?
Yes, both guest a
Signed-off-by: Nathan Froyd
---
target-mips/translate.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index c03d1bf..1157e97 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -2406,6 +2
The only thing to do here is to expose ISAMode to GDB and to set ISAMode
properly when we change the PC.
Signed-off-by: Nathan Froyd
---
gdbstub.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/gdbstub.c b/gdbstub.c
index 055093f..58a701b 100644
--- a/gdbstub.c
On Mon, Nov 23, 2009 at 10:30:56PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >On Mon, Nov 23, 2009 at 08:19:54PM +0100, Sebastian Herbszt wrote:
> >>Gleb Natapov wrote:
> >>>On Sun, Nov 22, 2009 at 09:01:45PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >On Sun, Nov
On 11/23/2009 03:17 AM, Anthony Liguori wrote:
You mean, each device would have multiple sections? We already use
chunks for each device state.
If they want to, yes.
We only migrate things that are guest visible. Everything else is left
to the user to configure. We wouldn't migrate the sta
On 11/20/09 18:41, Paul Brook wrote:
On Tuesday 17 November 2009, Gerd Hoffmann wrote:
Add a greeting string to CharDriverState which is printed after
initialization. Used to have the qemu vc consoles labeled. This
way we can avoid walking all the chardevs a second time after
initialization ju
On Sun, Nov 22, 2009 at 08:17:46PM -0600, Anthony Liguori wrote:
> Paolo Bonzini wrote:
> >
> >>I don't see how this fixes anything. If you used feature bits, how do
> >>you migrate from a version that has a feature bit that an older version
> >>doesn't know about? Do you just ignore it?
> >
> >I'd
The index property for both isa-serial and isa-parallel is declared as
hex number whereas it should be int. Fix it.
---
hw/parallel.c |2 +-
hw/serial.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/parallel.c b/hw/parallel.c
index 5ae8348..12693d4 100644
---
On 11/23/2009 09:26 AM, Gleb Natapov wrote:
> >I'd go with chunk instead of feature bits, specifying them like in
> >the PNG specification:
>
> You mean, each device would have multiple sections? We already use
> chunks for each device state.
>
Each device can send device info in multiple
On Mon, Nov 23, 2009 at 10:29:12AM +0100, Paolo Bonzini wrote:
> On 11/23/2009 09:26 AM, Gleb Natapov wrote:
> >I'd go with chunk instead of feature bits, specifying them like in
> >the PNG specification:
> >>>
> >>> You mean, each device would have multiple sections? We already use
>
On Thu, Nov 19, 2009 at 09:19:05AM -0600, Adam Litke wrote:
> Rusty and Anthony,
> If I've addressed all outstanding issues, please consider this patch for
> inclusion. Thanks.
>
> Changes since V2:
> - Increase stat field size to 64 bits
> - Report all sizes in kb (not pages)
> - Drop anon_pa
On Tue, Nov 17, 2009 at 06:32:20PM -0200, Luiz Capitulino wrote:
> Return a QDict with information about the just added device.
>
> This commit should not change user output.
>
> Please, note that this patch does not do error handling
> conversion. In error conditions the handler still calls
> mo
On 11/20/09 15:20, Mark McLoughlin wrote:
I've pushed a series of patches to the fix-announce-self-rfc.v2 branch
on my tree:
http://repo.or.cz/w/qemu/markmc.git
Looks much better.
If you have a special version for nics anyway (qemu_new_nic) you can
have that one take a NICConf parameter I
Gerd Hoffmann writes:
> The index property for both isa-serial and isa-parallel is declared as
> hex number whereas it should be int. Fix it.
Yes, that's much better.
On 11/22/2009 01:15, Stefan Reinauer wrote:
Dear x86 hardware and low-level software developers and enthusiasts!
coresystems GmbH is glad to finally release SerialICE 1.5, our
"Integrated Circuit Emulator over Serial".
SerialICE (http://www.serialice.com) is a BIOS/Firmware debugging tool.
It a
On Thu, Nov 19, 2009 at 01:11:56PM -0500, Steve Grubb wrote:
> On Thursday 19 November 2009 04:09:48 am Kevin Wolf wrote:
> > >> ...
> > >> In hw/e1000.c at line 89, vlan is declared to be 4 bytes. At line 382 is
> > >> an attempt to do a memmove over it with a size of 12.
> > >
> > > Obviously thi
On 11/20/09 22:33, H. Peter Anvin wrote:
+static const uint16_t isa_debugcon_iobase[MAX_DEBUGCON_PORTS] = { 0xe9 };
Not needed here.
+if (isa->index == -1)
+isa->index = index;
+if (isa->index>= MAX_DEBUGCON_PORTS)
+return -1;
+if (isa->iobase == -1)
+ isa->
On 11/23/2009 11:44 AM, Michael S. Tsirkin wrote:
On Thu, Nov 19, 2009 at 09:19:05AM -0600, Adam Litke wrote:
Rusty and Anthony,
If I've addressed all outstanding issues, please consider this patch for
inclusion. Thanks.
Changes since V2:
- Increase stat field size to 64 bits
- Report all
On Sun, Nov 22, 2009 at 12:07:50PM -0500, Kevin O'Connor wrote:
> On Sun, Nov 22, 2009 at 04:08:53PM +0200, Gleb Natapov wrote:
> > Microsoft SVVP (Server Virtualization Validation Program) expects
> > arbitrary SMBIOS field to have certain values otherwise it fails.
> > We all want to make Microso
On Sun, Nov 22, 2009 at 09:01:45PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote:
> >>
> >>Bad things could happen if someone modifies the BIOS because it's
> >>unprotected
> >>(e.g. VM crash).
> >>
> >BIOS is reloaded du
On Sun, Nov 22, 2009 at 11:04:34PM +0100, Sebastian Herbszt wrote:
> Kevin O'Connor wrote:
> >On Sun, Nov 22, 2009 at 05:38:09PM +0200, Gleb Natapov wrote:
> >>On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote:
> >>>// Write protect bios memory.
> >>>make_bios_readonly();
>
On Sun, Nov 22, 2009 at 10:38:42AM -0500, Kevin O'Connor wrote:
> On Sun, Nov 22, 2009 at 05:10:53PM +0200, Gleb Natapov wrote:
> > On Sun, Nov 22, 2009 at 04:07:56PM +0100, Sebastian Herbszt wrote:
> > > Gleb Natapov wrote:
> > > >May be make qemu to map it writable if isapc is specified.
> > >
>
On Sun, Nov 22, 2009 at 12:40:24PM -0500, Kevin O'Connor wrote:
> On Sun, Nov 22, 2009 at 05:38:09PM +0200, Gleb Natapov wrote:
> > On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote:
> > >// Write protect bios memory.
> > >make_bios_readonly();
> > Hmmm. How is tpr patching
On 11/23/2009 01:00 PM, Dor Laor wrote:
On 11/23/2009 11:44 AM, Michael S. Tsirkin wrote:
On Thu, Nov 19, 2009 at 09:19:05AM -0600, Adam Litke wrote:
Rusty and Anthony,
If I've addressed all outstanding issues, please consider this patch
for
inclusion. Thanks.
Changes since V2:
- Increase
On Sun, Nov 22, 2009 at 06:39:16PM +0100, Sebastian Herbszt wrote:
> >>Are the BIOS characteristics extension bytes valid if BIOS characteristics
> >>is not supported?
> >I have no idea. SVVP test complains though.
>
> p->bios_characteristics[0] = 0x08; /* BIOS characteristics not supported */
>
Microsoft SVVP (Server Virtualization Validation Program) expects
arbitrary SMBIOS field to have certain values otherwise it fails.
We all want to make Microsoft happy don't we? So lets put values MS
expects in there.
Values modified by the patch:
Type 0:
Bit 2 of byte 2 must be 1
Type 1:
M
Dor Laor wrote:
> In the last couple of days we discovered some issues regarding stable
> ABI and the robustness of the live migration protocol. Let's just jump
> right into it, ordered by complexity:
>
> 1. Control *every* feature exposed to the guest by qemu cmdline:
>
>While thinking on cro
On Mon, Nov 23, 2009 at 01:25:32PM +0100, Juan Quintela wrote:
> Gleb Natapov wrote:
> > On Sun, Nov 22, 2009 at 08:17:46PM -0600, Anthony Liguori wrote:
> >> Paolo Bonzini wrote:
> >> >
> >> >>I don't see how this fixes anything. If you used feature bits, how do
> >> >>you migrate from a version
On Mon, Nov 23, 2009 at 01:29:11PM +0100, Juan Quintela wrote:
> Gleb Natapov wrote:
> > On Mon, Nov 23, 2009 at 10:29:12AM +0100, Paolo Bonzini wrote:
> >> On 11/23/2009 09:26 AM, Gleb Natapov wrote:
> >> >I'd go with chunk instead of feature bits, specifying them like in
> >> >the PN
On Sat, 21 Nov 2009 11:02:41 +0100
Markus Armbruster wrote:
> Now, what should a client do when it discovers the monitor command it
> needs to use has grown a new error? Refuse to use the command for fear
> of having to present a sub-par error message to the user in case it
> fails?
What's you
On Sun, Nov 22, 2009 at 06:05:02PM +0100, Sebastian Herbszt wrote:
> v0.11.0-rc0-1677:
> use -cpu pentium and check SMBIOS tables. DMI type 4 entry is missing.
> Works with Bochs bios.
>
See two problems here. First one in seabios (patch attached). And the
second one in QEMU. Why pentium cpu type
Juan Quintela wrote:
Gleb Natapov wrote:
On Sun, Nov 22, 2009 at 08:17:46PM -0600, Anthony Liguori wrote:
Paolo Bonzini wrote:
I don't see how this fixes anything. If you used feature bits, how do
you migrate from a version that has a feature bit that an older version
doesn't k
On Sun, 22 Nov 2009 10:08:16 -0600
Anthony Liguori wrote:
> I'm certainly willing to consider alternative ways to do qmp_error() but
> taking a free form string is not an option in my mind. It goes against
> the fundamentals of what we're trying to build with QMP.
Agreed.
> So if you're oppo
On Sun, 22 Nov 2009 10:04:15 -0600
Anthony Liguori wrote:
> Luiz Capitulino wrote:
> >>> { "execute": "info", "arguments": { "item": "balloon" } }
> >>> {"return": 512}
> >>>
> >>> { "execute": "info", "arguments": { "item": "network" } }
> >>> {"return": [{"devices": [{"name": "user.0", "info":
Juan Quintela wrote:
Dor Laor wrote:
I will go further, and think that this kind of issues should be put into
the machine type.
I agree.
If you start qemu with -M pc-0.10, it should save the state in a 0.10
compatible way (that don't happens at the moment, but it should work
that way)
Luiz Capitulino wrote:
On Sun, 22 Nov 2009 10:08:16 -0600
Anthony Liguori wrote:
I'm certainly willing to consider alternative ways to do qmp_error() but
taking a free form string is not an option in my mind. It goes against
the fundamentals of what we're trying to build with QMP.
On Fri, 20 Nov 2009 15:06:26 +0100
Markus Armbruster wrote:
> Luiz Capitulino writes:
>
> > Each block device information is stored in a QDict and the
> > returned QObject is a QList of all devices.
> >
> > This commit should not change user output.
> >
> > Signed-off-by: Luiz Capitulino
> > -
On Fri, 20 Nov 2009 15:10:20 +0100
Markus Armbruster wrote:
> Luiz Capitulino writes:
>
> > Each device is represented by a QDict. The returned QObject is a QList
> > of all devices.
> >
> > This commit should not change user output.
> >
> > Signed-off-by: Luiz Capitulino
> > ---
> > monitor.
On Monday 23 November 2009, Gerd Hoffmann wrote:
> On 11/20/09 18:41, Paul Brook wrote:
> > On Tuesday 17 November 2009, Gerd Hoffmann wrote:
> >> Add a greeting string to CharDriverState which is printed after
> >> initialization. Used to have the qemu vc consoles labeled. This
> >> way we can a
On Mon, 23 Nov 2009 11:44:57 +0200
"Michael S. Tsirkin" wrote:
> On Tue, Nov 17, 2009 at 06:32:20PM -0200, Luiz Capitulino wrote:
> > Return a QDict with information about the just added device.
> >
> > This commit should not change user output.
> >
> > Please, note that this patch does not do
On Mon, 23 Nov 2009 07:11:53 -0600
Anthony Liguori wrote:
> Luiz Capitulino wrote:
> > On Sun, 22 Nov 2009 10:08:16 -0600
> > Anthony Liguori wrote:
> >
> >
> >> I'm certainly willing to consider alternative ways to do qmp_error() but
> >> taking a free form string is not an option in my min
Paolo Bonzini wrote:
On 11/23/2009 03:17 AM, Anthony Liguori wrote:
You mean, each device would have multiple sections? We already use
chunks for each device state.
If they want to, yes.
We only migrate things that are guest visible. Everything else is left
to the user to configure. We wo
Am 23.11.2009 um 14:34 schrieb Luiz Capitulino :
On Mon, 23 Nov 2009 07:11:53 -0600
Anthony Liguori wrote:
Luiz Capitulino wrote:
On Sun, 22 Nov 2009 10:08:16 -0600
Anthony Liguori wrote:
I'm certainly willing to consider alternative ways to do qmp_error
() but
taking a free form string
Excerpts from Anthony Liguori's message of Mon Nov 23 00:17:46 -0200 2009:
> Paolo Bonzini wrote:
> >
> >> I don't see how this fixes anything. If you used feature bits, how do
> >> you migrate from a version that has a feature bit that an older version
> >> doesn't know about? Do you just ignore i
Anthony Liguori wrote:
> Juan Quintela wrote:
>> Dor Laor wrote:
>>>
>>
>> My idea here is that we need to have further use of machine
>> descriptions, once that is done, we need something like a new property
>> for qdev (version?). Once there, each device could do:
>> - if version != last_
On 11/23/2009 02:51 PM, Eduardo Habkost wrote:
Right, but I wouldn't be surprised if a user complains that "I know that
my guest don't use that VM feature, so I want to be able to migrate to
an older version anyway".
That's a bit more tricky. What if the older version doesn't support
sound (j
On Mon, Nov 23, 2009 at 03:09:35PM +0100, Juan Quintela wrote:
> Gleb Natapov wrote:
> > On Mon, Nov 23, 2009 at 01:25:32PM +0100, Juan Quintela wrote:
> >> Gleb Natapov wrote:
> >> > On Sun, Nov 22, 2009 at 08:17:46PM -0600, Anthony Liguori wrote:
>
> > Yes, I proposed to send device state in m
Juan Quintela wrote:
Anthony Liguori wrote:
Juan Quintela wrote:
I'm not at all convinced that you can downgrade the version of a
device without exposing a functional change to a guest. In fact, I'm
pretty certain that it's provably impossible. Please give a counter
example of w
Gleb Natapov wrote:
My problem implementing optional features/sections/... is not the
savevm/VMState bits. At the end, implementing that is easy. What is
more dificult is once that a device have 5 features, what are the valid
combinations. i.e. if you have pci and msix features, msix requires
Eduardo Habkost wrote:
Migration needs to be conservative. There should be only two possible
outcomes: 1) a successful live migration or 2) graceful failure with the
source VM still running correctly. Silently ignoring things that could
affect the guests behavior means that it's possible that aft
On Mon, Nov 23, 2009 at 08:51:17AM -0600, Anthony Liguori wrote:
> Gleb Natapov wrote:
> My problem implementing optional features/sections/... is not the
> savevm/VMState bits. At the end, implementing that is easy. What is
> more dificult is once that a device have 5 features, what
Paolo Bonzini wrote:
On 11/23/2009 02:51 PM, Eduardo Habkost wrote:
Right, but I wouldn't be surprised if a user complains that "I know that
my guest don't use that VM feature, so I want to be able to migrate to
an older version anyway".
That's a bit more tricky. What if the older version doe
On Mon, Nov 23, 2009 at 03:21:24PM +0100, Paolo Bonzini wrote:
> On 11/23/2009 02:51 PM, Eduardo Habkost wrote:
>> Right, but I wouldn't be surprised if a user complains that "I know that
>> my guest don't use that VM feature, so I want to be able to migrate to
>> an older version anyway".
>
> That
Gleb Natapov wrote:
Then I don't see why Juan claims what he claims.
Live migration is unidirectional. As long as qemu can send out all of
the data without the stream closing, it will "succeed" on the source.
While this may sound like a bug, it's an impossible problem to solve as
it's d
On 11/23/09 14:26, Paul Brook wrote:
I thinking more that this should be done by the character backend itself. For
example, the "graphical" consoles should probably be putting this as part of
the window title
Doesn't work with vnc.
cheers,
Gerd
Eduardo Habkost wrote:
The pvclock MSRs are an example: if the guest is not using pvclock, not
restoring the MSRs won't make any difference. Strictly speaking, not
migrating them is wrong, but the user may argue that they know it won't
impact their guest OS, and that they want to take the risk.
On Monday 23 November 2009, Gerd Hoffmann wrote:
> On 11/23/09 14:26, Paul Brook wrote:
> > I thinking more that this should be done by the character backend itself.
> > For example, the "graphical" consoles should probably be putting this as
> > part of the window title
>
> Doesn't work with vnc
On Mon, Nov 23, 2009 at 04:10:48PM +0100, Gerd Hoffmann wrote:
> On 11/23/09 14:26, Paul Brook wrote:
> >I thinking more that this should be done by the character backend itself.
> >For
> >example, the "graphical" consoles should probably be putting this as part
> >of
> >the window title
>
> Do
Gerd Hoffmann wrote:
On 11/23/09 14:26, Paul Brook wrote:
I thinking more that this should be done by the character backend
itself. For
example, the "graphical" consoles should probably be putting this as
part of
the window title
Doesn't work with vnc.
A vc is what renders the for VNC so
On Mon, Nov 23, 2009 at 09:05:58AM -0600, Anthony Liguori wrote:
> Gleb Natapov wrote:
> >Then I don't see why Juan claims what he claims.
>
> Live migration is unidirectional. As long as qemu can send out all
> of the data without the stream closing, it will "succeed" on the
> source. While thi
Excerpts from Anthony Liguori's message of Mon Nov 23 12:49:23 -0200 2009:
> Juan Quintela wrote:
> > But if you know substitute qemu-0.11 and qemu-0.12 for RHEL5.4 and
> > RHEL5.4.1, you will see that the code bases are going to be really,
> > really similar. And if any savevm format is changed,
On 11/23/2009 04:22 PM, Gleb Natapov wrote:
As far as I remember the two general's problem talks about unreliable
channel, not unreliable nodes. Why not having destination send ACK/NACK
to the source when it knows that migration succeeded/failed. If source
gets NACK it continues, if it gets ACK i
Gleb Natapov wrote:
On Mon, Nov 23, 2009 at 09:05:58AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
Then I don't see why Juan claims what he claims.
Live migration is unidirectional. As long as qemu can send out all
of the data without the stream closing, it will "succeed"
Luiz Capitulino writes:
> On Fri, 20 Nov 2009 15:06:26 +0100
> Markus Armbruster wrote:
>
>> Luiz Capitulino writes:
[...]
>> > diff --git a/block.c b/block.c
>> > index 6fdabff..fc4e2f2 100644
>> > --- a/block.c
>> > +++ b/block.c
[...]
>> > -monitor_printf(mon, " removable=%d", bs->re
On Mon, Nov 23, 2009 at 09:00:05AM -0600, Anthony Liguori wrote:
>
> I think the problem is that you shouldn't be changing the guest visible
> state in a stable update of qemu. If you change the guest visible state
> in a stable update, then you won't be able to support live migration
> bet
Luiz Capitulino writes:
> On Fri, 20 Nov 2009 15:10:20 +0100
> Markus Armbruster wrote:
>
>> Luiz Capitulino writes:
>>
>> > Each device is represented by a QDict. The returned QObject is a QList
>> > of all devices.
>> >
>> > This commit should not change user output.
>> >
>> > Signed-off-by:
On Mon, Nov 23, 2009 at 09:32:48AM -0600, Anthony Liguori wrote:
> Gleb Natapov wrote:
> >On Mon, Nov 23, 2009 at 09:05:58AM -0600, Anthony Liguori wrote:
> >>Gleb Natapov wrote:
> >>>Then I don't see why Juan claims what he claims.
> >>Live migration is unidirectional. As long as qemu can send ou
On Mon, Nov 23, 2009 at 05:01:58PM +0100, Juan Quintela wrote:
> Anthony Liguori wrote:
> > Gleb Natapov wrote:
> > My problem implementing optional features/sections/... is not the
> > savevm/VMState bits. At the end, implementing that is easy. What is
> > more dificult is once that
Anthony Liguori writes:
> Markus Armbruster wrote:
>> I'm thinking and talking primarily about the protocol, and that probably
>> makes me too terse on implementation.
>>
>> I didn't mean to suggest that for adding the data part we should add new
>> arguments providing the data. That would be du
Gleb Natapov wrote:
On Mon, Nov 23, 2009 at 09:32:48AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
On Mon, Nov 23, 2009 at 09:05:58AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
Then I don't see why Juan claims what he claims.
Live migration is
Gleb Natapov wrote:
According to Anthony this is not a bug. Management has all the means to
resolve this situation properly. The bug would be if dst and src both
run or both exit.
Yup. And they do. If you do the same migration with libvirt, it will
fail gracefully with a -1 in the post_lo
On 11/23/09 16:20, Anthony Liguori wrote:
Gerd Hoffmann wrote:
On 11/23/09 14:26, Paul Brook wrote:
I thinking more that this should be done by the character backend
itself. For
example, the "graphical" consoles should probably be putting this as
part of
the window title
Doesn't work with vnc
On Mon, Nov 23, 2009 at 10:09:15AM -0600, Anthony Liguori wrote:
> Gleb Natapov wrote:
> >On Mon, Nov 23, 2009 at 09:32:48AM -0600, Anthony Liguori wrote:
> >>Gleb Natapov wrote:
> >>>On Mon, Nov 23, 2009 at 09:05:58AM -0600, Anthony Liguori wrote:
> Gleb Natapov wrote:
> >Then I don't see
Luiz Capitulino writes:
> On Sat, 21 Nov 2009 11:02:41 +0100
> Markus Armbruster wrote:
>
>> Now, what should a client do when it discovers the monitor command it
>> needs to use has grown a new error? Refuse to use the command for fear
>> of having to present a sub-par error message to the use
Eduardo Habkost wrote:
Excerpts from Anthony Liguori's message of Mon Nov 23 12:49:23 -0200 2009:
Juan Quintela wrote:
But if you know substitute qemu-0.11 and qemu-0.12 for RHEL5.4 and
RHEL5.4.1, you will see that the code bases are going to be really,
really similar. And if any savev
Gleb Natapov wrote:
I am OK with management being responsible to sort things out. Juan
said that destination can't abort migration in the middle, so I pointed
out easy solution that will work in 99.999% cases.
I think there's something elegant about doing migration in a
unidirectional strea
Juan Quintela wrote:
you can weasel the way you want (I can also do it).
Customer had: 5.4 <-> 5.4 migration working (suboptimally)
Now appears 5.4.1 that works best with migration. But he want to do the
migration in two steps:
migrate from qemu 5.4 -> 5.4.1, and be able to migrate back if he
Excerpts from Anthony Liguori's message of Mon Nov 23 14:16:39 -0200 2009:
> Eduardo Habkost wrote:
> > Excerpts from Anthony Liguori's message of Mon Nov 23 12:49:23 -0200 2009:
> >>>
> >> In our own stable branch, we do not introduce any savevm changes. I
> >> would recommend the same p
1 - 100 of 132 matches
Mail list logo
