Thanks for the feedback.  <div><br></div><div>I as already planning to have a dedicated management network and had also discussed the need for some network protocol to share state information.   I now feel that using a network to share state information is the right solution in our case.  </div>
<div><br></div><div>While xenstore looks interesting, I am hesitant to implement anything that is Xen specific at this time.   I want to be able to move to KVM or &quot;the next big thing&quot; as simply as possible.</div>
<div><br></div><div>Thanks again,</div><div>   David</div><div><br><br><div class="gmail_quote">On Thu, Jul 23, 2009 at 4:53 AM, Christopher G. Stach II <span dir="ltr">&lt;<a href="mailto:cgs@ldsys.net">cgs@ldsys.net</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">----- &quot;R P Herrold&quot; &lt;<a href="mailto:herrold@centos.org">herrold@centos.org</a>&gt; wrote:<br>

<br>
&gt; The addition of a new private network segment seems like<br>
&gt; overkill and needless additional fragility and complexity --<br>
&gt; if one to one, use a remote syslog setup (viz., over UDP); if<br>
&gt; one to many (domU), use a multicast sender and listeners.<br>
&gt;<br>
&gt; Run either on the existing network seqment shared by the domUs<br>
&gt; and dom0 already.<br>
<br>
</div>It&#39;s just RAM until you add a physical interface to the bridge, and then it&#39;s just Ethernet.  It would be difficult to argue that using either is fragile or complex.  Even compared against your suggestion, the only difference is isolation, the general rule for administrative networks.<br>

<br>
If the skill level involved is negative, perhaps if the person is coming from the Device Manager space, maybe the steps of adding a bridge, a vif entry for each VM, and configuring the interface within each VM is way too much to handle.  However, IIRC, virtual network bridges are one of the documented Xen use cases and are entry level stuff.  The cost and added risk thereof are next to zero.  Being that worried about fragility in your basic set of capabilities is silly, unless you have evidence to the contrary.<br>

<br>
If the messages are used to trigger things like shutdowns, scale back services, or be published in any way that could be dangerous (inadvertently notifying customers/competitors/attackers that your hardware sucks or what your system architecture looks like), you&#39;ll need to involve crypto unless you don&#39;t care if anyone inside shuts down your VMs.  syslogd would not help in this case, but at least SNMP could.<br>

<br>
--<br>
<font color="#888888">Christopher G. Stach II<br>
</font><div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
CentOS-virt mailing list<br>
<a href="mailto:CentOS-virt@centos.org">CentOS-virt@centos.org</a><br>
<a href="http://lists.centos.org/mailman/listinfo/centos-virt" target="_blank">http://lists.centos.org/mailman/listinfo/centos-virt</a><br>
</div></div></blockquote></div><br></div>