Prashanth Radhakrishnan
2005-Sep-30 11:52 UTC
[Xen-devel] CoW memory and Parallax questions.
Does Xen-unstable do Copy-on-Write sharing of memory between VMs ? If not, is someone working on it ? I last see a mention about Micheal Vrable working on it back in Oct 2004 - http://lists.xensource.com/archives/html/xen-devel/2004-10/msg00470.html. Also curious to find out the status on Parallax; is someone working on adding persistent caching, remote block access and other features as described in the parallax paper (it seems that the current implementation has remote access or local access) ? thanks, prashanth _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, Sep 30, 2005 at 05:52:20AM -0600, Prashanth Radhakrishnan wrote:> Does Xen-unstable do Copy-on-Write sharing of memory between VMs ? > If not, is someone working on it ? > I last see a mention about Micheal Vrable working on it back in Oct 2004 > - http://lists.xensource.com/archives/html/xen-devel/2004-10/msg00470.html.Yes, I''m still working on it. The focus of that work was copy-on-write sharing of memory for the purposes of building a (virtual) network of honeypot systems. We have a paper in SOSP this year, talking about that work and the copy-on-write memory implementation. See http://www.cs.ucsd.edu/~mvrable/papers/2005-sosp-potemkin.pdf for some information. I''m presently working on updating and cleaning that work up. --Michael Vrable _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Also curious to find out the status on Parallax; is someone working on > adding persistent caching, remote block access and other features as > described in the parallax paper (it seems that the current implementation > has remote access or local access) ?Parallax work is ongoing as well... the block tap source was brought up to speed with the new tools interface about a month ago and the parallax sources will follow shortly. If there is something specific that you are interested in (or interested in working on ;) ) let me know... a. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jacob Faber Kloster
2005-Oct-03 16:20 UTC
Re: [Xen-devel] CoW memory and Parallax questions.
Now when the topic of Copy-on-Write memory sharing is up. It might be in place to tell that we (a group of tree master students), will be doing work on content based Copy-on-Write memory sharing. Similar to what is implemented in VMWare''s ESX server. See http://www.waldspurger.org/carl/papers/esx-mem-osdi02.pdf We have contacted Michael Vrable about his approach, and it is likely that our code will be an extension of his. Best regards Jacob Faber Kloster (group email d515a.cs.aau.dk) On Fri, 2005-09-30 at 05:52 -0600, Prashanth Radhakrishnan wrote:> Does Xen-unstable do Copy-on-Write sharing of memory between VMs ? > If not, is someone working on it ? > I last see a mention about Micheal Vrable working on it back in Oct 2004 > - http://lists.xensource.com/archives/html/xen-devel/2004-10/msg00470.html. > > Also curious to find out the status on Parallax; is someone working on > adding persistent caching, remote block access and other features as > described in the parallax paper (it seems that the current implementation > has remote access or local access) ? > > thanks, > prashanth > > _______________________________________________ > 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
They aren't mutually exclusive, but a content-based approach, although more flexible, seems like it would inevitably be much heavier weight. What is your solution targeted towards? -Kip On 10/3/05, Jacob Faber Kloster <jk@cs.aau.dk> wrote:> > Now when the topic of Copy-on-Write memory sharing is up. It might be in > place to tell that we (a group of tree master students), will be doing > work on content based Copy-on-Write memory sharing. Similar to what is > implemented in VMWare's ESX server. See > http://www.waldspurger.org/carl/papers/esx-mem-osdi02.pdf > > We have contacted Michael Vrable about his approach, and it is likely > that our code will be an extension of his. > > Best regards > Jacob Faber Kloster (group email d515a.cs.aau.dk <http://d515a.cs.aau.dk>) > > On Fri, 2005-09-30 at 05:52 -0600, Prashanth Radhakrishnan wrote: > > Does Xen-unstable do Copy-on-Write sharing of memory between VMs ? > > If not, is someone working on it ? > > I last see a mention about Micheal Vrable working on it back in Oct 2004 > > - > http://lists.xensource.com/archives/html/xen-devel/2004-10/msg00470.html. > > > > Also curious to find out the status on Parallax; is someone working on > > adding persistent caching, remote block access and other features as > > described in the parallax paper (it seems that the current > implementation > > has remote access or local access) ? > > > > thanks, > > prashanth > > > > _______________________________________________ > > 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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jacob Gorm Hansen
2005-Oct-04 08:53 UTC
Re: [Xen-devel] CoW memory and Parallax questions.
My take on that would be to introduce read-only pages and a context index (tree or hashtable) in Xen, and then handle the CoW part in the guest OSes. That removes the need for any policy on how to handle overcommits in Xen or Dom0, in the case where all domUs decide to fill up their pages with random data. Jacob _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jacob Faber Kloster
2005-Oct-04 11:14 UTC
Re: [Xen-devel] CoW memory and Parallax questions.
On Mon, 2005-10-03 at 12:12 -0700, Kip Macy wrote:> They aren''t mutually exclusive, but a content-based approach, although > more flexible, seems like it would inevitably be much heavier weight. > What is your solution targeted towards? > > -KipIndeed a combination of the two could be in order to avoid some unnecessary processing. Also there is no doubt that content based sharing uses more processing time, but it is more generally applicable than the ''forking'' scheme. For instance it seems hard to come up with a scheme that allows sharing of memory when migrating VMs. Furthermore as VMs, in the forking scheme, have run for a longer period of time, we expect the percent of sharing to decrease. Content based sharing will allow us to identify sharing that was not possible at the time of forking. Our solution is thus meant as an option when starting several VMs that are similar, but not identical from start. Perhaps the processing overhead of doing content based sharing is too large, but we can''t really know for certain before we have done some experiments. Best regards Jacob Faber Kloster (group email d515a@cs.aau.dk) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jacob Faber Kloster
2005-Oct-04 11:45 UTC
Re: [Xen-devel] CoW memory and Parallax questions.
That certainly sounds like an interesting approach. Our immediate approach was something along the lines of making a separate service, on the hypervisor level of privilege, with complete overview and control of the memory. Doing the content based sharing scheme will, as you also noted, open up the possibility of overcommitment of memory. Some kind of scheduling will be needed to handle this. One solution could be to suspend a VM to disk or introduce a swapping.. But at this point in time we are not focusing on any specific solution, we are just investigating whether it is possible and feasible to share memory. Best regards Jacob Faber Kloster (group email d515a@cs.aau.dk) On Tue, 2005-10-04 at 10:53 +0200, Jacob Gorm Hansen wrote:> My take on that would be to introduce read-only pages and a context > index (tree or hashtable) in Xen, and then handle the CoW part in the > guest OSes. That removes the need for any policy on how to handle > overcommits in Xen or Dom0, in the case where all domUs decide to fill > up their pages with random data. > > Jacob_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I don't think HV level privilege is necessary. Take a look at the mergemem work. A service running in the background in DOM0 is a potentially viable approach. -Kip On 10/4/05, Jacob Faber Kloster <jk@cs.aau.dk> wrote:> > That certainly sounds like an interesting approach. Our immediate > approach was something along the lines of making a separate service, on > the hypervisor level of privilege, with complete overview and control of > the memory. Doing the content based sharing scheme will, as you also > noted, open up the possibility of overcommitment of memory. Some kind of > scheduling will be needed to handle this. One solution could be to > suspend a VM to disk or introduce a swapping.. > > But at this point in time we are not focusing on any specific solution, > we are just investigating whether it is possible and feasible to share > memory. > > Best regards > Jacob Faber Kloster (group email d515a@cs.aau.dk) > > > On Tue, 2005-10-04 at 10:53 +0200, Jacob Gorm Hansen wrote: > > My take on that would be to introduce read-only pages and a context > > index (tree or hashtable) in Xen, and then handle the CoW part in the > > guest OSes. That removes the need for any policy on how to handle > > overcommits in Xen or Dom0, in the case where all domUs decide to fill > > up their pages with random data. > > > > Jacob > > > _______________________________________________ > 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
Xin Zhao
2005-Oct-20 17:45 UTC
[Xen-devel] cannot get console access to newly created domain
After a DomU died, I tried to do "xm destroy 5" and recreate the domain with the same block device and kernel. But "xm list" gave me the following results: Name Id Mem(MB) CPU VCPU(s) State Time(s) Domain-0 0 249 0 1 r----- 232.4 Normal-Domain 5 0 0 1 ----cd 19.0 Normal-Domain 5 0 0 1 ----cd 19.0 Why did I get two domains with the same domID? Also, when I do "xm console 6", I cannot access the new domain. I also tried "xm console 5", doesn''t work either. Any insignt about this? Thanks, Xin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ewan Mellor
2005-Oct-20 17:57 UTC
Re: [Xen-devel] cannot get console access to newly created domain
On Thu, Oct 20, 2005 at 01:45:18PM -0400, Xin Zhao wrote:> After a DomU died, I tried to do "xm destroy 5" and recreate the domain > with the same block device and kernel. But "xm list" gave me the following > results: > > Name Id Mem(MB) CPU VCPU(s) State Time(s) > Domain-0 0 249 0 1 r----- 232.4 > Normal-Domain 5 0 0 1 ----cd 19.0 > Normal-Domain 5 0 0 1 ----cd 19.0 > > Why did I get two domains with the same domID? Also, when I do "xm console > 6", I cannot access the new domain. I also tried "xm console 5", doesn''t > work either.That''s not very pretty. Which changeset are you using, and could you please post your /var/log/xend.log and /var/log/xend-debug.log? Thanks, Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
zhaoxin
2005-Oct-20 18:10 UTC
RE: [Xen-devel] cannot get console access to newly created domain
Thank you for your help! This is the information of last change set for my current system /*****************************************/ changeset: 7076:46046d5fb354 tag: tip user: emellor@ewan date: Tue Sep 27 17:09:46 2005 +0100 summary: Remove unused import, mark unused variables. /*****************************************/ The xend.log and xend-debug.log are attached with this email, please check them out. Thanks, Xin -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Ewan Mellor Sent: Thursday, October 20, 2005 1:58 PM To: Xin Zhao Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] cannot get console access to newly created domain On Thu, Oct 20, 2005 at 01:45:18PM -0400, Xin Zhao wrote:> After a DomU died, I tried to do "xm destroy 5" and recreate the domain > with the same block device and kernel. But "xm list" gave me the following > results: > > Name Id Mem(MB) CPU VCPU(s) State Time(s) > Domain-0 0 249 0 1 r----- 232.4 > Normal-Domain 5 0 0 1 ----cd 19.0 > Normal-Domain 5 0 0 1 ----cd 19.0 > > Why did I get two domains with the same domID? Also, when I do "xm console > 6", I cannot access the new domain. I also tried "xm console 5", doesn''t > work either.That''s not very pretty. Which changeset are you using, and could you please post your /var/log/xend.log and /var/log/xend-debug.log? Thanks, Ewan. _______________________________________________ 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
Ewan Mellor
2005-Oct-20 18:31 UTC
Re: [Xen-devel] cannot get console access to newly created domain
On Thu, Oct 20, 2005 at 02:10:54PM -0400, zhaoxin wrote:> Thank you for your help! > > This is the information of last change set for my current system > /*****************************************/ > changeset: 7076:46046d5fb354 > tag: tip > user: emellor@ewan > date: Tue Sep 27 17:09:46 2005 +0100 > summary: Remove unused import, mark unused variables. > /*****************************************/Eek! That''s far too old, I''m afraid. There have been many bugs related to domain shutdown fixed in the last three weeks. You will have to upgrade (or ignore the problem). Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel