(追記)
この問題は libvirt-0.6.3-33.el5_5.3 で解消されました（CentOS 5.x でも利用可能になっています）。

環境は CentOS 5.5 (x86_64)、libvirt-0.6.3-33.el5_5.1、bridge-utils-1.1-2。KVM と書きましたが、libvirt の問題なので Xen でも同様かと思われます。
ここでは、VM をブリッジ接続している状況 ... 例えば br0 に対して eth0 (実際のネットワークに接続するインターフェース) と vnet0 (仮想マシンのインターフェース) を enslave させているような場合 ... を前提としています。

さて、virsh でゲストを start したり destroy したりすると、ホスト側の SSH が一時的に応答しなくなる場合があります。この問題は、ブリッジに接続しているインターフェースが変更されるとブリッジの MAC アドレスが変更されてしまうことに起因します。具体的には、

1. （Linux の）ブリッジは enslave された Ethernet インターフェースの持つ MAC アドレスのうち、一番小さいものをブリッジの MAC アドレスとして採用する
2. libvirt は vnetX に対してランダムに MAC アドレスを付与する(*1)
3. よって、VM が start ないし destroy され、ブリッジに参加しているインターフェースが変更されたとき、ブリッジの MAC アドレスが変更されてしまう場合がある

ということです。

これによって問題が生じるのは、そのブリッジインターフェースに割り当てた IP アドレスを使用して何らかのネットワークサービス（SSH による管理などを含む）を提供している場合です。このケースでは、MAC アドレスが頻繁に変更されるのは好ましくありません（クライアントは ARP キャッシュの期限が切れるまでアクセスできなくなってしまうため）。

この問題は既に報告されており、仮想マシンに付与する MAC アドレスの 1 オクテット目を FE にすることで対処されるようです。2010-07-26 に Fixed In Version: libvirt-0.6.3-35.el5 になっていますが、RHEL5 にもまだ出ていないようなので、CentOS で提供されるまではもうちょっとかかりそうですね(*2)。

(*1) ランダムと言っても locally administered フラグは立っているので、（実際のネットワークに接続する）Ethernet インターフェースの MAC アドレスの 1 オクテット目が 00 で始まる場合、問題は起きません（Lucky you!）。今回トラブルが起きたのは HP ML110 G5 の on-board NIC で、OUI が 78:E7:D1 となっていました。
(*2) 個人的には、とりあえず、ifcfg-eth0 に MACADDR=02:00:00:00:00:00 と書いてしまうことにしました（locally administered な MAC アドレスの中で最小なので、ブリッジ中で常に最小であることが保証される）。KVM ホストが複数ある場合は悩ましいですね...。