Avi Kivity wrote:
On 04/08/2010 10:30 AM, Yoshiaki Tamura wrote:
To answer your question, it should be possible to implement.
The down side is that after going into KVM to make the guest state to
consistent, we need to go back to qemu to actually transfer the guest,
and this bounce would introduce another overhead if I'm understanding
correctly.
Yes. It should be around a microsecond or so, given you will issue I/O
after this I don't think this will affect performance.
That is a good news.
And yes, all I need is some consistent state to resume VM from, which
must be able to continue I/O operations, like writing to disks and
sending ack over the network. If I can guarantee this, sending the VM
state after completing output is acceptable.
I suggest you start with this. If it turns out performance is severely
impacted, we can revisit instruction completion. If performance is
satisfactory, then we'll be able to run Kemari with older kernels.
I was almost to say yes here, but let me ask one more question.
BTW, thank you two for taking time for this discussion which isn't a topic on
KVM itself.
If I transferred a VM after I/O operations, let's say the VM sent an TCP ACK to
the client, and if a hardware failure occurred to the primary during the VM
transferring *but the client received the TCP ACK*, the secondary will resume
from the previous state, and it may need to receive some data from the client.
However, because the client has already receiver TCP ACK, it won't resend the
data to the secondary. It looks this data is going to be dropped. Am I missing
some point here?
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
