I posted this page on the wiki last week, which is a feature we intend to implement for Fedora 12:
http://fedoraproject.org/wiki/Features/Hostinfo
Any comments?
Rich.
"Allow a virtual machine to see information and statistics from the host operating system, under narrow and strictly controlled conditions and only at the discretion of the host administrator.
Detailed Description
Allow a virtual machine to look at host information (such as number of physical, not just virtual CPUs), and statistics like the load on the host. Users have asked for this primarily as a diagnostic tool -- for example, poor performance of a virtual machine might be caused by excessive load on the host.
Normally we try to isolate virtual machines from accessing any such details from the host, and there are very good reasons for that too, such as security of the host, commercial confidentiality, and the privacy of other virtual machines running on the host. As a result, at the moment there is no mechanism for accessing host information.
We propose to add a feature which allows the host administrator, at their discretion, and only of limited data to limited virtual machines, to export host information and statistics to virtual machines.
Administrators will need to:
* explicitly enable this feature, * select the virtual machines and/or data they wish to be seen in guests, * select the frequency that guests can ask for data.
The mechanism will be a daemon running on the host which collects the statistics (see below for what). The information will be exported to guests over a spare (virtual) serial port or through the qemu/kvm vmchannel feature, whichever is available.
Guests will request information by sending a plain text command to the serial port, and will receive information in the form of a simple, plain text message. No special drivers or software are required by the guest.
On Tue, Jun 16, 2009 at 11:34 AM, Richard W.M. Jones rjones@redhat.comwrote:
I posted this page on the wiki last week, which is a feature we intend to implement for Fedora 12:
http://fedoraproject.org/wiki/Features/Hostinfo
Any comments?
Thanks for the heads up.
My only comment is that generally hosts are already some kind of monitoring daemon (e.g. collectd) -- and this will mean they may have to end up running another.
If there one tht RHEL customers tend to run? If so, perhaps a plugin to that to extract the information would be simpler / less intrusive.
For the guest side, it sounds like you will be inventing a text based protocol to ask for statistical information about the host -- I just wonder if such a protocol already exists. And if there is already a client for that, then the guest side would just be the channel hookup, rather than any client dev.
Cheers, Anand
On Tue, Jun 16, 2009 at 02:40:34PM +0100, Anand Kumria wrote:
On Tue, Jun 16, 2009 at 11:34 AM, Richard W.M. Jones rjones@redhat.comwrote:
I posted this page on the wiki last week, which is a feature we intend to implement for Fedora 12:
http://fedoraproject.org/wiki/Features/Hostinfo
Any comments?
Thanks for the heads up.
My only comment is that generally hosts are already some kind of monitoring daemon (e.g. collectd) -- and this will mean they may have to end up running another.
If there one tht RHEL customers tend to run? If so, perhaps a plugin to that to extract the information would be simpler / less intrusive.
Good point, but there is certainly no standard for monitoring daemons. Some will be running proprietary daemons.
For the guest side, it sounds like you will be inventing a text based protocol to ask for statistical information about the host -- I just wonder if such a protocol already exists. And if there is already a client for that, then the guest side would just be the channel hookup, rather than any client dev.
I'm not aware of an existing protocol for that. Does anyone have any suggestions?
Rich.
On Tue, Jun 16, 2009 at 12:08 PM, Richard W.M. Jonesrjones@redhat.com wrote:
On Tue, Jun 16, 2009 at 02:40:34PM +0100, Anand Kumria wrote:
For the guest side, it sounds like you will be inventing a text based protocol to ask for statistical information about the host -- I just wonder if such a protocol already exists. And if there is already a client for that, then the guest side would just be the channel hookup, rather than any client dev.
I'm not aware of an existing protocol for that. Does anyone have any suggestions?
Can't the data be published via SNMP and the admin could configure what ever method to expose that to potential users?
(Re-sent with fedora-virt in the To:).
On Tue, Jun 16, 2009 at 12:14:59PM -0400, James Hubbard wrote:
On Tue, Jun 16, 2009 at 12:08 PM, Richard W.M. Jonesrjones@redhat.com wrote:
On Tue, Jun 16, 2009 at 02:40:34PM +0100, Anand Kumria wrote:
For the guest side, it sounds like you will be inventing a text based protocol to ask for statistical information about the host -- I just wonder if such a protocol already exists. And if there is already a client for that, then the guest side would just be the channel hookup, rather than any client dev.
I'm not aware of an existing protocol for that. Does anyone have any suggestions?
Can't the data be published via SNMP and the admin could configure what ever method to expose that to potential users?
It is not explicit in Richard's feature page, but a core goal of this hostinfo service is to avoid any use of networking. We don't want to presume that a guest has a NIC, nor that the host has a configured NIC on the same LAN as the guest.
Regards, Daniel
On Tue, Jun 16, 2009 at 05:20:08PM +0100, Daniel P. Berrange wrote:
On Tue, Jun 16, 2009 at 12:14:59PM -0400, James Hubbard wrote:
On Tue, Jun 16, 2009 at 12:08 PM, Richard W.M. Jonesrjones@redhat.com wrote:
On Tue, Jun 16, 2009 at 02:40:34PM +0100, Anand Kumria wrote:
For the guest side, it sounds like you will be inventing a text based protocol to ask for statistical information about the host -- I just wonder if such a protocol already exists. And if there is already a client for that, then the guest side would just be the channel hookup, rather than any client dev.
I'm not aware of an existing protocol for that. Does anyone have any suggestions?
Can't the data be published via SNMP and the admin could configure what ever method to expose that to potential users?
It is not explicit in Richard's feature page, but a core goal of this hostinfo service is to avoid any use of networking. We don't want to presume that a guest has a NIC, nor that the host has a configured NIC on the same LAN as the guest.
Indeed - it's quite common for guests to have no common network with the host. In oVirt for example you have two physical network cards.
Rich.
On Tue, Jun 16, 2009 at 12:20 PM, Daniel P. Berrangeberrange@redhat.com wrote:
On Tue, Jun 16, 2009 at 12:14:59PM -0400, James Hubbard wrote:
On Tue, Jun 16, 2009 at 12:08 PM, Richard W.M. Jonesrjones@redhat.com wrote:
On Tue, Jun 16, 2009 at 02:40:34PM +0100, Anand Kumria wrote:
For the guest side, it sounds like you will be inventing a text based protocol to ask for statistical information about the host -- I just wonder if such a protocol already exists. And if there is already a client for that, then the guest side would just be the channel hookup, rather than any client dev.
I'm not aware of an existing protocol for that. Does anyone have any suggestions?
Can't the data be published via SNMP and the admin could configure what ever method to expose that to potential users?
It is not explicit in Richard's feature page, but a core goal of this hostinfo service is to avoid any use of networking. We don't want to presume that a guest has a NIC, nor that the host has a configured NIC on the same LAN as the guest.
So for the situation where there is no NIC/network you have the following: a. Display, keyboard, mouse, sound exported in some way that allows use without the machine having network access. (This could be useful for secure environments.) b. VM starts image where batch processing occurs. No user connectivity. I don't understand how providing that information to the batch processor could help, unless it decides to wait until the machine isn't loaded.
For not on the same LAN: a. The admin still could provision snmp to send results to the appropriate host.
As far as it being a serial device, why not export a host serial device that any guest could connect to and make it readonly from the guest and not even allow the guest to send data to the host? The host would constantly send data to the serial device.
I'm not knocking the idea. it just seems like a feature waiting for abuse or a potential security problem.
On Tue, Jun 16, 2009 at 12:38:37PM -0400, James Hubbard wrote:
So for the situation where there is no NIC/network you have the following: a. Display, keyboard, mouse, sound exported in some way that allows use without the machine having network access. (This could be useful for secure environments.)
It isn't that there is no network, it's that the guest and the host networks are strictly separated from each other, often physically.
Rich.
On 06/16/2009 01:03 PM, Richard W.M. Jones wrote:
It isn't that there is no network, it's that the guest and the host networks are strictly separated from each other, often physically.
Could you clarify that - you mean like PCI network card assignment? Because the guest can't be safe from its host, from a security stance, unless SELinux does more than I realize.
It would be straightforward to create an isolated monitoring bridge with a private address space if one wanted to do SNMP between guests and hosts. (OK, to be fair, I haven't ever tried this with virtual interfaces).
Alton Brown is always asking at the kitchen gadget store, "OK, but what else can it do?" I'm not saying there's not a use for this special-purpose device, but is it a one-off or the start of more general-purpose infrastructure?
That armchair quarterbacking aside - the Wiki page says you have customers asking for this. Have they already ruled out an SNMP approach? Too complex, too heavy-weight, etc.?
-Bill
On Jun 16, 2009, at 11:21, Bill McGonigle wrote:
It would be straightforward to create an isolated monitoring bridge with a private address space if one wanted to do SNMP between guests and hosts. (OK, to be fair, I haven't ever tried this with virtual interfaces).
Setting up "private address space" is a lot more configuration (and things to go wrong) than configuring a port number for a virtual serial port.
If you want SNMP, just have the SNMP daemon talk to the serial port and relay the information.
- ask
On Tue, Jun 16, 2009 at 02:21:02PM -0400, Bill McGonigle wrote:
On 06/16/2009 01:03 PM, Richard W.M. Jones wrote:
It isn't that there is no network, it's that the guest and the host networks are strictly separated from each other, often physically.
Could you clarify that - you mean like PCI network card assignment? Because the guest can't be safe from its host, from a security stance, unless SELinux does more than I realize.
It would be straightforward to create an isolated monitoring bridge with a private address space if one wanted to do SNMP between guests and hosts. (OK, to be fair, I haven't ever tried this with virtual interfaces).
There's all sorts of issues with this: Should it be firewalled (on either the host or guest side)? Will other daemons on the host accidentally bind to ports on this interface, and how do we stop that?
How does it appear in the guest? As an extra network interface?
What "private address space" should we give it? The guest could and likely is using RFC1918 addresses for its own purposes.
This is the motivation for wanting 'vmchannel' - a simple, network- independent guest to host communication channel. However we don't have vmchannel now, and are no nearer to having it, so we use serial ports instead.
I'd also dispute the statement that "it would be straightforward to create an isolated monitoring bridge with a private address space if one wanted to do SNMP between guests and hosts." There's nothing at all straightforward about setting up interfaces, bridges or SNMP. Compared to setting up an extra serial port which involves precisely adding a <serial/> clause to the libvirt configuration.
Rich.
-
Anand Kumria -
Ask Bjørn Hansen -
Bill McGonigle -
Daniel P. Berrange -
James Hubbard -
Richard W.M. Jones