[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Guest to Host communication

On Thu, Oct 31, 2013 at 5:13 PM, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
On 31/10/13 16:08, Jose A. Lopes wrote:
On Thu, Oct 31, 2013 at 02:21:38PM +0000, George Dunlap wrote:
On Tue, Oct 22, 2013 at 2:42 PM, Jose A. Lopes <jabolopes@xxxxxxxxxx> wrote:
On Tue, Oct 22, 2013 at 01:18:56PM +0000, Paul Durrant wrote:
-----Original Message-----
From: Jose A. Lopes [mailto:jabolopes@xxxxxxxxxx]
Sent: 22 October 2013 13:49
To: Paul Durrant
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] Guest to Host communication


If I understood correctly, Xenstore requires writing a driver and
loading it inside the VM.  Is this correct?

Well, yes you'll need some code in the guest, but drivers already exist for linux and windows so you could just use them.

If so, then it seems this approach would require writing different
drivers for different OSes, such as, Linux and Windows.  Currently, we
are just exploring different design options and we would like to aim
at a uniform approach across different OSes. Is there an option like that ?

What option do you expect that doesn't involve writing at least some code for each OS you want to use?
We were thinking of simply attaching a device.
For example, add a SSD disk in DomU which is backed in Dom0 by a file.
Is this possible?
Of course you can attach as many disks as you want; or you could just
have dom0 look for a file in the primary filesystem.  But whether you
use the primary filesystem or a secondary one, you still have the
basic problem of introspection: if this is going to be a filesystem,
then there may be a difference at any given time between what domU
thinks the state of the filesystem is, and what dom0 can see on the
disk (because there may be things in domU's buffer cache which haven't
"hit the disk" yet).
We have changed our use case to the situation where the instance
writes a few bytes to this device.  However, Ganeti only needs this
information once the instance has stopped.  Therefore, while the
instance is running it can write and overwrite the information because
it is not important.

I wonder if it is possible to change the caching policy of the device
in order to immediately flush the writes.  This is not so important
because I imagine that by the time the instance has stopped (if it
didn't crash), the cache should have been flushed.

We were however thinking about a usb serial device to make it easier
to do successive writes within the instance.

Oh, right -- in that case, probably the easiest thing to do would be to just create a file in the guest filesystem and have your tools look inside to see if it's there.  You could have a secondary disk just for that purpose, if that makes it easier to make it the same across instances.

When you say "look inside" the filesystem do you mean to mount that filesystem
in the host OS? If so, it seems that it is very dangerous to mount guest filesystems
due to a number of exploits.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.