Re: [PATCH] qemu: qemu_fopen_fd: differentiate between reader and writer user

[Uri Lublin <uri@il.qumranet.com>]

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.