Re: [Qemu-devel] [PATCH 00/21] Kemari for KVM 0.2

[Yoshiaki Tamura]

2010/11/29 Paul Brook <address@hidden>:
>> 2010/11/29 Paul Brook <address@hidden>:
>> >> >> Could you formulate the constraints so developers are aware of them
>> >> >> in the future and can protect the codebase.  How about expanding the
>> >> >> Kemari wiki pages?
>> >> >
>> >> > If you like the idea above, I'm happy to make the list also on
>> >> > the wiki page.
>> >>
>> >> Here's a different question: what requirements must an emulated device
>> >> meet in order to be added to the Kemari supported whitelist?  That's
>> >> what I want to know so that I don't break existing devices and can add
>> >> new devices that work with Kemari :).
>> >
>> > Why isn't it completely device agnostic? i.e. if a device has to care
>> > about Kemari at all (of vice-versa) then IMO you're doing it wrong. The
>> > whole point of the internal block/net APIs is that they isolate the host
>> > implementation details from the device emulation.
>>
>> You're right "theoretically".  But what I've learned so far,
>> there are cases like virtio-net and e1000 woks but virtio-blk
>> doesn't.  "Theoretically", any emulated device should be able to
>> get into the whitelist if the event-tap is properly implemented
>> but sometimes it doesn't seem to be that simple.
>>
>> To answer Stefan's question, there shouldn't be any requirement
>> for a device, but must be tested with Kemari.  If it doesn't work
>> correctly, the problems must be fixed before adding to the list.
>
> What exactly are the problems? Is this a device bus of a Kemari bug?
> If it's the former then that implies you're imposing additional requirements
> that weren't previously part of the API.  If the latter, then it's a bug like
> any other.

It's a problem if devices don't continue correctly upon failover.
I would say it's a bug of live migration (not all of course)
because Kemari is just live migrating at specific points.

Yoshi

>
> Paul
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to address@hidden
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>