From: George Dunlap <george.dunlap@eu.citrix.com>
To: "Jose A. Lopes" <jabolopes@google.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: Guest to Host communication
Date: Thu, 31 Oct 2013 16:13:50 +0000 [thread overview]
Message-ID: <527281BE.7080008@eu.citrix.com> (raw)
In-Reply-To: <20131031160835.GA30966@google.com>
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@google.com> wrote:
>>> On Tue, Oct 22, 2013 at 01:18:56PM +0000, Paul Durrant wrote:
>>>>> -----Original Message-----
>>>>> From: Jose A. Lopes [mailto:jabolopes@google.com]
>>>>> Sent: 22 October 2013 13:49
>>>>> To: Paul Durrant
>>>>> Cc: xen-devel@lists.xenproject.org
>>>>> Subject: Re: [Xen-devel] Guest to Host communication
>>>>>
>>>>> Hi,
>>>>>
>>>>> 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.
-George
next prev parent reply other threads:[~2013-10-31 16:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-22 7:59 Guest to Host communication Jose A. Lopes
2013-10-22 8:48 ` Paul Durrant
2013-10-22 12:48 ` Jose A. Lopes
2013-10-22 13:18 ` Paul Durrant
2013-10-22 13:42 ` Jose A. Lopes
2013-10-31 14:21 ` George Dunlap
2013-10-31 16:08 ` Jose A. Lopes
2013-10-31 16:13 ` George Dunlap [this message]
2013-10-31 18:42 ` Jose A. Lopes
2013-10-31 20:02 ` Ian Campbell
2013-11-04 10:51 ` Jose A. Lopes
2013-10-22 13:54 ` Konrad Rzeszutek Wilk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=527281BE.7080008@eu.citrix.com \
--to=george.dunlap@eu.citrix.com \
--cc=Paul.Durrant@citrix.com \
--cc=jabolopes@google.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.