A formal definition of {\em strong virtual synchrony}, capturing the semantics of virtual synchrony as implemented in Horus, is presented. This definition has the nice property that every message is delivered within the view in which it was sent. However, it is shown that in order to implement strong virtual synchrony, the application program has to block messages during view changes. An alternative definition, called {\em weak virtual synchrony}, which can be implemented without blocking messages, is then presented. This definition still guarantees that messages will be delivered within the view in which they were sent, only that it uses a slightly weaker notion of what the view in which a message was sent is. An implementation of weak virtual synchrony that does not block messages during view changes is developed, and it is shown how to use a system that provides weak virtual synchrony even when strong virtual synchrony is actually needed. To capture additional ordering requirements, the definition of {\em ordered virtual synchrony} is presented. Finally, it is discussed how to extend the definitions in order to cope with the fact that a process can become a member of more than one group.