CentOS virt - Jul 2009 - How to pass messages from dom0 to domU??

I apologize if this is a newbie question, but I have been unable to work out
how to do this.
I am adding code to my installation on dom0 (running CentOS 5.3) to monitor
for hardware faults.   If there is an issue, I want to propagate the status
to all of the domUs (running CentOS 4.x or CentOS 5) running on the host.

What are my options to do this??

Thanks!

   David
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.centos.org/pipermail/centos-virt/attachments/20090722/914f080c/attachment-0006.html>

From: David Knierim, Wednesday, July 22, 2009 3:18 PM
>I apologize if this is a newbie question, but I have been unable to work 
>out how to do this.
>I am adding code to my installation on dom0 (running CentOS 5.3) to monitor 
>for hardware faults.   If there is an issue, I want to propagate the status 
>to all of the domUs (running CentOS 4.x or CentOS 5) running on the host.
>What are my options to do this??
  I would use shared file space.  Maybe an NFS share that all machines could 
access...  That way it is not restricted to virtual machines running on that 
server.  If you expanded to 2 servers for increased capacity or fault 
tolerance, you would not have to redesign it.

----- "David Knierim" <dknierim at gmail.com> wrote:
> I am adding code to my installation on dom0 (running CentOS 5.3) to
> monitor for hardware faults. If there is an issue, I want to propagate
> the status to all of the domUs (running CentOS 4.x or CentOS 5)
> running on the host.
How complicated do you want to get?  There are a couple simple ways, but they
require some very basic coding:

1. Share a tiny block device as read-only with every concerned guest domain. 
Write to the block device in dom0 and read from the block device periodically in
domU.  Treat it as a semaphore, but remember that your reads in domU may be
goofed up and you may end up going through two or more cycles before a complete
read can occur.

2. Share a private virtual network segment with every connected guest domain. 
Write a packet in dom0 and read in domU.  This has the benefit that you can
later expand this to a VLAN or physical segment for cross-physical-host
communication.  Make up whatever protocol you want if the network will only be
used for this.  If you want to have some foresight, just use UDP on some
unassigned port and then make up whatever protocol you want.  This isn't
much different than just using SNMP SET, except your SNMP daemon won't be
exposed to other networks.  That is probably better, anyway.

If you want more of a supported framework, you can go to NFS, OCFS2, or GFS. 
The problem I see with this, for your simple use case, is that you are touching
the kernel in dom0.  This adds risk to stability.

-- 
Christopher G. Stach II

----- "David Knierim" <dknierim at gmail.com> wrote:
> I am adding code to my installation on dom0 (running CentOS 5.3) to
> monitor for hardware faults. If there is an issue, I want to propagate
> the status to all of the domUs (running CentOS 4.x or CentOS 5)
> running on the host.
You can also use xenstore, but you may not want to screw around with it.  I
figured I'd let you know, anyway.

-- 
Christopher G. Stach II

----- "R P Herrold" <herrold at centos.org> wrote:
> The addition of a new private network segment seems like 
> overkill and needless additional fragility and complexity -- 
> if one to one, use a remote syslog setup (viz., over UDP); if 
> one to many (domU), use a multicast sender and listeners.
> 
> Run either on the existing network seqment shared by the domUs 
> and dom0 already.
It's just RAM until you add a physical interface to the bridge, and then
it'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.

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.

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'll need to involve crypto unless you don't
care if anyone inside shuts down your VMs.  syslogd would not help in this case,
but at least SNMP could.

-- 
Christopher G. Stach II