Re: [Qemu-devel] [PATCH 1/2] Add virtagent file system freeze/thaw

[Jes Sorensen]

On 02/03/11 18:41, Michael Roth wrote:
> On 02/02/2011 02:48 AM, Jes Sorensen wrote:
>> Yes very much so[1] - one reason why it would be nice to have virtagent
>> use threads to execute the actual commands. We should probably add a
>> flag to agent commands indicating whether they issue disk I/O or not, so
>> we can block attempts to execute commands that do so, while the guest is
>> frozen.
> 
> **Warning, epic response**
> 
> For things like logging and i/o on a frozen system...I agree we'd need
> some flag for these kinds of situations. Maybe a disable_logging()
> flag....i really don't like this though... I'd imagine even syslogd()
> could block virtagent in this type of situation, so that would need to
> be disabled as well.

One way to resolve this would be to have the logging handled in it's own
thread, which uses non blocking calls to do the actual logging.
Obviously we'd have to use a non file system based communication method
between the main thread and the logging thread :)

> But doing so completely subverts our attempts and providing proper
> accounting of what the agent is doing to the user. A user can freeze the
> filesystem, knowing that logging would be disabled, then prod at
> whatever he wants. So the handling should be something specific to
> fsfreeze, with stricter requirements:
> 
> If a user calls fsfreeze(), we disable logging, but also disable the
> ability to do anything other than fsthaw() or fsstatus(). This actually
> solves the potential deadlocking problem for other RPCs as well...since
> they cant be executed in the first place.

I disagree that we should block all calls, except for fsfreeze/fsstatus/
fsthaw in this case. There are other calls that could be valid in this
situations, so I think it needs to be evaluated on a case by case basis.

> So a solution for these situations is still needed, and I'm starting to
> agree that threads are needed, but I don't think we should do RPCs
> concurrently (not sure if that's what is being suggested or not). At
> least, there's no pressing reason for it as things currently stand
> (there aren't currently any RPCs where fast response times are all that
> important, so it's okay to serialize them behind previous RPCs, and
> HMP/QMP are command at a time), and it's something that Im fairly
> confident can be added if the need arises in the future.

Eventually I think we will need to be able to support concurrent RPC
calls. There can be situations where an operation takes a long time
while it is valid to be able to ping the guest agent to verify that it
is still alive etc.

Cheers,
Jes