Xen devel - Mar 2006 - RE: Re: [Xen-users] How to share data between guestdomains

>-----Original Message-----
>From: xen-devel-bounces@lists.xensource.com
>[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Xin Zhao
>Sent: 2006年3月21日 1:25
>To: Yura Pismerov
>Cc: xen-devel@lists.xensource.com
>Subject: Re: [Xen-devel] Re: [Xen-users] How to share data between
>guestdomains
>
>The benefits of VL inlcude:
>1. A VM can take advantage of the global disk cache and benefit from
>previous data accesses from other VMs. We will expect better performance.
>2. VL allows finer granularity of sharing, instead of directory level
>sharing.
>3. The shared file system is transparent to guest applications and
>should be easily adopted.
>4. VL allows centralized software updates. These updates can take effect
>right after the files are updated.
>
>We will put a detailed description of VL soon, if someone is interested
>in that. :)
Hope to see your detailed subscription. It is really good news, especially for
multi Guests requirement, such as testing. Is it based on Xen0? Is it for both
para-virtualization XenU and HVM?
>
>Xin
>
>Yura Pismerov wrote:
>> I found that using NFS for things like this makes much more sense.
>> You can run the domU with NFS root (read-only) and map certain areas
you
>> need read/write
>> to tmpfs by mounting them with "mount --bind" in Linux). For
example, if
>> I use NFS root and want my /etc
>> be writable I can always write its content to a tmpfs mounted area and
>> run "mount --bind /tmpfs/etc /etc".
>> This also will solve problems with centralized package updates when not
>> only /usr is being updated, but some other areas (eg. /etc, /var/lib).
>> You want those areas be shared between domU''s as well.
>>
>>
>> Molle Bestefich wrote:
>>
>>
>>> Todd D. Esposito wrote:
>>>
>>>
>>>
>>>> However, on that note, I wonder if you could mount the same
file system,
>>>> say something like /usr, into multiple domU''s READ
ONLY.
>>>>
>>>>
>>>>
>>> That works for me.
>>>
>>> What doesn''t work is mounting that file/device READ/WRITE
in one domU
>>> to update the filesystem.  For that, I have to take down *all*
domUs.
>>> Not good...
>>>
>>> (When I try I get a vbd: error saying "already in use".)
>>>
>>> (I know about caching and that I need eg. a cluster-aware
filesystem
>>> to do this.)
>>>
>>> I''ve spent a couple of hours hunting through various Xen
source files.
>>> There''s a lot of Python functions that are only 3-5 lines
long and
>>> which does little else than calling the next function, which makes
it
>>> very hard to figure out what''s going on :-/.
>>>
>>> Could one of you devel guys please let me know where I need to go
to
>>> remove this silly limitation? :-)
>>>
>>> _______________________________________________
>>> Xen-users mailing list
>>> Xen-users@lists.xensource.com
>>> http://lists.xensource.com/xen-users
>>>
>>>
>>>
>>
>>
>>
>
Best Regards,
Yongkang (Kangkang) 永康

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> Hope to see your detailed subscription. It is really good news, 
> especially for multi Guests requirement, such as testing. Is it based on 
> Xen0? Is it for both para-virtualization XenU and HVM?
Thought I''d just add that VL has similar characteristics to my XenFS 
project. Both share some common objectives but differ in some details. 
Eventually, we may be able to share features.

The filesystem sharing situation under Xen should improve substantially in 
the future.

http://wiki.xensource.com/xenwiki/XenFS

Cheers,
Mark
>>
>>Xin
>>
>>Yura Pismerov wrote:
>>> I found that using NFS for things like this makes much more sense.
>>> You can run the domU with NFS root (read-only) and map certain
areas you
>>> need read/write
>>> to tmpfs by mounting them with "mount --bind" in Linux).
For example, if
>>> I use NFS root and want my /etc
>>> be writable I can always write its content to a tmpfs mounted area
and
>>> run "mount --bind /tmpfs/etc /etc".
>>> This also will solve problems with centralized package updates when
not
>>> only /usr is being updated, but some other areas (eg. /etc,
/var/lib).
>>> You want those areas be shared between domU''s as well.
>>>
>>>
>>> Molle Bestefich wrote:
>>>
>>>
>>>> Todd D. Esposito wrote:
>>>>
>>>>
>>>>
>>>>> However, on that note, I wonder if you could mount the same
file
>>>>> system, say something like /usr, into multiple
domU''s READ ONLY.
>>>>>
>>>>>
>>>>>
>>>> That works for me.
>>>>
>>>> What doesn''t work is mounting that file/device
READ/WRITE in one domU
>>>> to update the filesystem.  For that, I have to take down *all*
domUs.
>>>> Not good...
>>>>
>>>> (When I try I get a vbd: error saying "already in
use".)
>>>>
>>>> (I know about caching and that I need eg. a cluster-aware
filesystem
>>>> to do this.)
>>>>
>>>> I''ve spent a couple of hours hunting through various
Xen source files.
>>>> There''s a lot of Python functions that are only 3-5
lines long and
>>>> which does little else than calling the next function, which
makes it
>>>> very hard to figure out what''s going on :-/.
>>>>
>>>> Could one of you devel guys please let me know where I need to
go to
>>>> remove this silly limitation? :-)
>>>>
>>>> _______________________________________________
>>>> Xen-users mailing list
>>>> Xen-users@lists.xensource.com
>>>> http://lists.xensource.com/xen-users
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>Best Regards,
>Yongkang (Kangkang) ÓÀ¿µ
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel