hony Liguori wrote:
Uri Lublin wrote:
In the scenario above (with ACK/GO messages), SRC _does_ know that DST
have failed (as it does not receive ACK). With ACK/GO messages we only
need third party involvement to handle a scenario where GO does not
reach DST. Without ACK/GO messages we need third party involvement for
almost any state-load function failure. In other words the
risk/exposure is smaller with ACK/GO messages.
I think this is a scenario where we have to be careful about layering in
the design. The core migration protocol is a mechanism. The goal is to
not implement policy. Having an exchange of ack/go messages may
increase reliability but they don't do so in a perfect way. How many
times you go back and forth therefore becomes a policy which is based on
how important reliability is to you trading off latency.
I think it's either use ACK/GO messages (one round trip) or not.
If you have a
high latency network, the round trip cost of an ack/go message may
introduce unwanted latency (which translates to VM downtime). Moreover,
if you have a third party orchestrating everything, it's totally
unnecessary downtime.
Agreed. That's what I meant when I mentioned ACK/GO messages slow the migration
a bit on the average/good case.
This is not to say there is no place for QEMU to support policies. They
should be layered in such a way that they don't burden everyone though.
The idea behind using migration protocols is to help facilitate this.
I think the tcp: protocol should remain a pure migration-over-tcp
transport. I think there is room for implementing another migration
protocol that was maybe geared toward more average users. An ack/go
message may be appropriate for this. I really think it should also have
a daemon associated with it that could automatically spawn QEMU
instances. I've always felt the ssh: protocol should provide this but
it proved less popular than I expected it to be.
This is where management tools start to play.
Although very elegant (getting security+compression+auto-spawning "for free"),
the problem with the ssh migration protocol is the "local" params of qemu/kvm.
For example if VM1 on host A use vnc port : and VM2 on host B use port :9 ,
then ssh-migration of VM1 from A to B would fail.
Anyway, my point is that if you want an ack/go message, you should
encapsulate the existing protocol within another protocol (that has it's
own versioning) and introduce a new transport.
OK.
Since in both cases we must have a third party involvement in the
worst case, and since on the good/normal case those messages slow down
the migration process a bit (and complicate the code a bit), I do not
mind dropping those messages. I just wanted to make sure we all
understand their benefit. We can always add them later if we'll "miss"
them (if we'll find out they are more useful then we think now).
In any case, we need to think of a way to get the migration status on
the destination. A minimum is to term_printf a message specifying that
status.
What's the use case for this? In what circumstances would you have no
idea of what was happening on DST such that you'd need to get this from
the SRC?
I meant that you need to get DST view of migration status from DST. So a
management tool, or a user, would get migration status from both SRC and DST and
would be able to tell if migration was successful. That too is not that
important on the normal case, but may be valuable on a bad case.
Regards,
Uri.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
