hi, is x2d2 (the minimal xend replacement in C if I understand correctly) still alive? I do not have bk at the moment, but grepping on x2d2 in the Changelog file only has a comment back from November. I can make it compile by removing -Werror from the Makefile, but is anyone using it and working on it, or is it a dead end? Jacob ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It''s fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Tue, 18 Jan 2005, Jacob Gorm Hansen wrote:> is x2d2 (the minimal xend replacement in C if I understand correctly) > still alive? I do not have bk at the moment, but grepping on x2d2 in the > Changelog file only has a comment back from November. I can make it > compile by removing -Werror from the Makefile, but is anyone using it > and working on it, or is it a dead end?I need it for bproc machines, so definitely have interest in it. ron ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It''s fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Jacob Gorm Hansen wrote:> hi, > > is x2d2 (the minimal xend replacement in C if I understand correctly) > still alive? I do not have bk at the moment, but grepping on x2d2 in > the Changelog file only has a comment back from November. I can make > it compile by removing -Werror from the Makefile, but is anyone using > it and working on it, or is it a dead end?I don''t think so. It shouldn''t actually work anymore. It doesn''t do proper notifications on event channels. There''s also a bug in the way ports are allocated. Is there still interest in x2d2 (or any C-based minimal xend)? I think I could fix x2d2 pretty easily. Regards,> Jacob > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It''s fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xen-devel >-- Anthony Liguori anthony@codemonkey.ws ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It''s fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Anthony Liguori wrote:> Jacob Gorm Hansen wrote: > >> hi, >> >> is x2d2 (the minimal xend replacement in C if I understand correctly) >> still alive? I do not have bk at the moment, but grepping on x2d2 in >> the Changelog file only has a comment back from November. I can make >> it compile by removing -Werror from the Makefile, but is anyone using >> it and working on it, or is it a dead end? > > > I don''t think so. It shouldn''t actually work anymore. It doesn''t do > proper notifications on event channels. There''s also a bug in the way > ports are allocated. > > Is there still interest in x2d2 (or any C-based minimal xend)? I think > I could fix x2d2 pretty easily. >Yes, lots of interest from me, the python xend effectively keeps me from running Xen 2.0, so I am still stuck with 1.3. The stock xend uses too much memory, provides too much functionality, and depends on too many third-party packages -- not the ideal specs for the minimal trusted computing base I am trying to develop :-( Jacob ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It''s fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
We are in the process of some fairly major revisions to the control tools. I think that the general expectation is that 3.0 will show some pretty big changes to the control interfaces and tools. The unstable tree now has a control switch (xcs) which sits under xend and allows other applications to be written to use the control channels without needing to modify xend. We are hoping to move towards small, single-purpose management tools in dom0. This should all start to appear in the unstable tree over the next couple of months. a. On Wed, 19 Jan 2005 01:58:46 -0800, Jacob Gorm Hansen <jacobg@diku.dk> wrote:> Anthony Liguori wrote: > > Jacob Gorm Hansen wrote: > > > >> hi, > >> > >> is x2d2 (the minimal xend replacement in C if I understand correctly) > >> still alive? I do not have bk at the moment, but grepping on x2d2 in > >> the Changelog file only has a comment back from November. I can make > >> it compile by removing -Werror from the Makefile, but is anyone using > >> it and working on it, or is it a dead end? > > > > > > I don''t think so. It shouldn''t actually work anymore. It doesn''t do > > proper notifications on event channels. There''s also a bug in the way > > ports are allocated. > > > > Is there still interest in x2d2 (or any C-based minimal xend)? I think > > I could fix x2d2 pretty easily. > > > > Yes, lots of interest from me, the python xend effectively keeps me from > running Xen 2.0, so I am still stuck with 1.3. The stock xend uses too > much memory, provides too much functionality, and depends on too many > third-party packages -- not the ideal specs for the minimal trusted > computing base I am trying to develop :-( > > Jacob > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It''s fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xen-devel >------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It''s fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> hi, > > is x2d2 (the minimal xend replacement in C if I understand correctly) > still alive? I do not have bk at the moment, but grepping on x2d2 in the > Changelog file only has a comment back from November. I can make it > compile by removing -Werror from the Makefile, but is anyone using it > and working on it, or is it a dead end? > > JacobI used it quite recently. It seemed to work with two little modifications: a) removing -Werror (you got as far as that) b) when creating event channels (there are 2 places in x2d2 that do that) you need to initialise the port numbers to 0 (0 means first available). Cheers Gregor -- Quidquid latine dictum sit, altum viditur --- Anon ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It''s fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Andrew Warfield wrote:>We are in the process of some fairly major revisions to the control >tools. I think that the general expectation is that 3.0 will show >some pretty big changes to the control interfaces and tools. The >unstable tree now has a control switch (xcs) which sits under xend and > >Wow. I wrote the same exact thing about a week or two ago. I took a slightly different approach though. I opened a unix domain socket to receive messages on and also opened up ptys for each domain. The daemon takes care of multiplexing and demultiplexing the messages so if your app sends a message, it will only get that response. What are your thoughts on this approach? I particularly like the idea of piping the console data to a pty. Regards,>allows other applications to be written to use the control channels >without needing to modify xend. We are hoping to move towards small, >single-purpose management tools in dom0. > >This should all start to appear in the unstable tree over the next >couple of months. > > >-- Anthony Liguori anthony@codemonkey.ws ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It''s fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Wed, 19 Jan 2005, Anthony Liguori wrote:> Is there still interest in x2d2 (or any C-based minimal xend)? I think I > could fix x2d2 pretty easily.we could really use it here. ron ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It''s fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> Andrew Warfield wrote: > > >We are in the process of some fairly major revisions to the control > >tools. I think that the general expectation is that 3.0 will show > >some pretty big changes to the control interfaces and tools. The > >unstable tree now has a control switch (xcs) which sits under xend and > > > > > Wow. I wrote the same exact thing about a week or two ago. > > I took a slightly different approach though. I opened a unix domain > socket to receive messages on and also opened up ptys for each domain. > > The daemon takes care of multiplexing and demultiplexing the messages so > if your app sends a message, it will only get that response. > > What are your thoughts on this approach? I particularly like the idea > of piping the console data to a pty.We thought about the pty approach, but resisted it because we thought that in most setups there''d need to be a daemon running in user-space to export the console (typically over the network), and hence it wasn''t worth the effort of turning it into a pty in the kernel. The current approach also minimizes the amount of OS-specific Xen privileged interface code, which keeps the people interested in using OSes other than Linux in domain 0 happy. I could be persuaded, though... Ian ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It''s fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Another option is to give the console drivers their own device channel (i.e. take them off the control rings) and then just provide a separate backend for them. From there dom0 could export them however it wanted to without depending on the other control tools at all. a. On Wed, 19 Jan 2005 16:36:45 +0000, Ian Pratt <Ian.Pratt@cl.cam.ac.uk> wrote:> > Andrew Warfield wrote: > > > > >We are in the process of some fairly major revisions to the control > > >tools. I think that the general expectation is that 3.0 will show > > >some pretty big changes to the control interfaces and tools. The > > >unstable tree now has a control switch (xcs) which sits under xend and > > > > > > > > Wow. I wrote the same exact thing about a week or two ago. > > > > I took a slightly different approach though. I opened a unix domain > > socket to receive messages on and also opened up ptys for each domain. > > > > The daemon takes care of multiplexing and demultiplexing the messages so > > if your app sends a message, it will only get that response. > > > > What are your thoughts on this approach? I particularly like the idea > > of piping the console data to a pty. > > We thought about the pty approach, but resisted it because we > thought that in most setups there''d need to be a daemon running > in user-space to export the console (typically over the network), > and hence it wasn''t worth the effort of turning it into a pty in > the kernel. > > The current approach also minimizes the amount of OS-specific Xen > privileged interface code, which keeps the people interested in > using OSes other than Linux in domain 0 happy. > > I could be persuaded, though... > > Ian >------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It''s fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
It''s very important to us, for what we do, to get Python completely out of the picture. Is that possible? ron ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Having a wiki will be extremely useful but until then do people want to post feature requests here? I know some things I''d like to see: 1) domain management delegation (allow user `x'' to administrator domain id y) 2) control interface multiplexing (xsc does this) 3) intelligent dom0 rebooting (autostart domains like Xend does) 4) domain consoles interfaced through pseudo-terminals I''m very willing to help out coding the new management tools. I want to see what people think is useful first. Regards, On Wed, 2005-01-19 at 09:47, Ronald G. Minnich wrote:> On Wed, 19 Jan 2005, Anthony Liguori wrote: > > > Is there still interest in x2d2 (or any C-based minimal xend)? I think I > > could fix x2d2 pretty easily. > > we could really use it here. > > ron > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It''s fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xen-devel-- Anthony Liguori Linux Technology Center (LTC) - IBM Austin E-mail: aliguori@us.ibm.com Phone: (512) 838-1208 ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
---- Original message ---->From: Ian Pratt <Ian.Pratt@cl.cam.ac.uk> > >We thought about the pty approach, but resisted it because we >thought that in most setups there''d need to be a daemon running >in user-space to export the console (typically over the network), >and hence it wasn''t worth the effort of turning it into a pty in >the kernel.The daemon we wrote does the pty stuff in user space. It''s particularly useful in unix becase pty''s can be connected to all sorts of interesting things like remote Xterms and ssh sessions. One particularly useful feature of pty''s is delegation. Since you can set pty''s with standard unix file permissions (maybe even posix acls?) you can delegate console access in a pretty sophisticated way. You cannot easily do that with normal sockets.>The current approach also minimizes the amount of OS-specific Xen >privileged interface code, which keeps the people interested in >using OSes other than Linux in domain 0 happy.I agree here. pts''s are part of Posix though. Of course more esoteric OSes that don''t have Posix support will need another mechanism but they''ll probably need a lot of work anyway to be used in dom0.>I could be persuaded, though...That''s always a good sign :-) Regards,>Ian------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Wed, 19 Jan 2005, Ian Pratt wrote:> The current approach also minimizes the amount of OS-specific Xen > privileged interface code, which keeps the people interested in using > OSes other than Linux in domain 0 happy.this is a good goal. ron ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> Having a wiki will be extremely useful but until then do > people want to > post feature requests here? I know some things I''d like to see:We''ll hopefully have the wiki up fairly soon, but the list is a good place for discusion.> 1) domain management delegation (allow user `x'' to > administrator domain > id y)I''d prefer not to tie domain administration privilege to the concept of unix uid''s, but have some higher level concept of identification/authorization the tools know about.> 2) control interface multiplexing (xsc does this) > > 3) intelligent dom0 rebooting (autostart domains like Xend does)We''ve been thinking on terms of having a ''persistent'' flag on domains to inidicate that they should always be running, and hence started on boot.> 4) domain consoles interfaced through pseudo-terminalsI''m not sure of the advantage of this, as its frequent you want to export them over a network, either via tcp, or ssl. Thanks, Ian ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Wed, 19 Jan 2005, Ian Pratt wrote:> > 1) domain management delegation (allow user `x'' to > > administrator domain > > id y) > > I''d prefer not to tie domain administration privilege to the concept of > unix uid''s, but have some higher level concept of > identification/authorization the tools know about.yep, since plan 9 has no uids ...> I''m not sure of the advantage of this, as its frequent you want to > export them over a network, either via tcp, or ssl.agree ... ron ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> The daemon we wrote does the pty stuff in user space. It''s > particularly > useful in unix becase pty''s can be connected to all sorts of > interesting > things like remote Xterms and ssh sessions.OK, if it''s user space, I''m sold, providing that there''s also the option to export via a tcp socket as we currently do. Ian ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Ian Pratt wrote:> OK, if it''s user space, I''m sold, providing that there''s also the option > to export via a tcp socket as we currently do.Is there any possibility of exporting the console sockets as UNIX domain sockets instead of as INET sockets? I''d really rather not have those exposed to the world. I can do firewalling to control access to them, but it''d be nice to be able to easily leverage UNIX permissions and POSIX ACLs to control access, rather than having to do iptables gymnastics. -- Derrik Pates demon@devrandom.net ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Wed, 19 Jan 2005, Derrik Pates wrote:> Is there any possibility of exporting the console sockets as UNIX domain > sockets instead of as INET sockets? I''d really rather not have those > exposed to the world. I can do firewalling to control access to them, > but it''d be nice to be able to easily leverage UNIX permissions and > POSIX ACLs to control access, rather than having to do iptables > gymnastics.Both options are nice. I would find INET sockets might handy for cluster console. ron ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Wed, 2005-01-19 at 14:37, Ian Pratt wrote:> I''d prefer not to tie domain administration privilege to the concept of > unix uid''s, but have some higher level concept of > identification/authorization the tools know about.Yeah, I understand this desire. The unix security model is not very sophisticated. However, it''s awfully convenient to use user-based security. Particularly in dealing with networks. If security can be based on unix users then with pam, you automatically have security solutions that work in a kerberos, ldap, or even windows network environment. It doesn''t have to be the only way or even the preferred way.> > 2) control interface multiplexing (xsc does this) > > > > 3) intelligent dom0 rebooting (autostart domains like Xend does) > > We''ve been thinking on terms of having a ''persistent'' flag on domains to > inidicate that they should always be running, and hence started on boot.A domain information database would be useful. It would be nice for it to be accessible via many applications though. Otherwise, you have the problem you have in Xend right now where the domain ''names'' are not visible to other applications that can still see the domain.> > 4) domain consoles interfaced through pseudo-terminals > > I''m not sure of the advantage of this, as its frequent you want to > export them over a network, either via tcp, or ssl.You''re right. It''s not a make-or-break feature. But it is still useful for some scenarios. Thanks,> Thanks, > Ian-- Anthony Liguori Linux Technology Center (LTC) - IBM Austin E-mail: aliguori@us.ibm.com Phone: (512) 838-1208 ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Wed, 19 Jan 2005, Anthony Liguori wrote:> I don''t think so. It shouldn''t actually work anymore. It doesn''t do proper > notifications on event channels. There''s also a bug in the way ports are > allocated. > > Is there still interest in x2d2 (or any C-based minimal xend)? I think I > could fix x2d2 pretty easily.definitely. ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Wed, 19 Jan 2005, Ronald G. Minnich wrote:> It''s very important to us, for what we do, to get Python completely out > of the picture. Is that possible?I would also like to ship a smaller Xen daemon to the Fedora users, since I expect that quite a few of the first wave of Xen users will be students with more time than hardware - and they will care about having a small Xen daemon. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Wed, 19 Jan 2005, Anthony Liguori wrote:> 4) domain consoles interfaced through pseudo-terminals5) add new devices to a running virtual machine 6) have an API that can be used by higher level management software, so people can script the deployment of virtual machines, in a similar way to how they script the deployment of physical systems today. Eg. the installer could use this API to create and configure a virtual system, when the user wants to install an additional virtual machine. 7) is light weight, ie. can run with very little memory overhead, so little memory is spent on domain 0 and more memory is left over for eg. the testing of rawhide ;)> I''m very willing to help out coding the new management tools. I want to > see what people think is useful first.I''d be willing to ship experimental management tools in Fedora, so there is a userbase to test the software. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On 20 Jan 2005, at 19:36, Rik van Riel wrote:> On Wed, 19 Jan 2005, Anthony Liguori wrote: > >> 4) domain consoles interfaced through pseudo-terminals > > 5) add new devices to a running virtual machine > > 6) have an API that can be used by higher level management > software, so people can script the deployment of virtual > machines, in a similar way to how they script the > deployment of physical systems today. Eg. the installer > could use this API to create and configure a virtual > system, when the user wants to install an additional > virtual machine. > > 7) is light weight, ie. can run with very little memory > overhead, so little memory is spent on domain 0 and > more memory is left over for eg. the testing of rawhide ;) > >> I''m very willing to help out coding the new management tools. I want >> to >> see what people think is useful first. > > I''d be willing to ship experimental management tools in Fedora, > so there is a userbase to test the software.I''m interested on anything related to Xen :-) ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Wed, 2005-01-19 at 10:12 +0000, Andrew Warfield wrote:> We are in the process of some fairly major revisions to the control > tools. I think that the general expectation is that 3.0 will show > some pretty big changes to the control interfaces and tools. The > unstable tree now has a control switch (xcs) which sits under xend and > allows other applications to be written to use the control channels > without needing to modify xend. We are hoping to move towards small, > single-purpose management tools in dom0. > > This should all start to appear in the unstable tree over the next > couple of months. > > a. >Do you have plans you can share regarding these revisions to the control tools? I am exploring needs within my organization for management tools on Xen. Besides being interested in what you have planned, I can contribute assistance - development, testing, etc. Thanks. Michael> On Wed, 19 Jan 2005 01:58:46 -0800, Jacob Gorm Hansen <jacobg@diku.dk> wrote: > > Anthony Liguori wrote: > > > Jacob Gorm Hansen wrote: > > > > > >> hi, > > >> > > >> is x2d2 (the minimal xend replacement in C if I understand correctly) > > >> still alive? I do not have bk at the moment, but grepping on x2d2 in > > >> the Changelog file only has a comment back from November. I can make > > >> it compile by removing -Werror from the Makefile, but is anyone using > > >> it and working on it, or is it a dead end? > > > > > > > > > I don''t think so. It shouldn''t actually work anymore. It doesn''t do > > > proper notifications on event channels. There''s also a bug in the way > > > ports are allocated. > > > > > > Is there still interest in x2d2 (or any C-based minimal xend)? I think > > > I could fix x2d2 pretty easily. > > > > > > > Yes, lots of interest from me, the python xend effectively keeps me from > > running Xen 2.0, so I am still stuck with 1.3. The stock xend uses too > > much memory, provides too much functionality, and depends on too many > > third-party packages -- not the ideal specs for the minimal trusted > > computing base I am trying to develop :-( > > > > Jacob > >>-- Michael Hohnbaum 503 578 5486 hohnbaum@us.ibm.com t/l 775 5486 ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> Do you have plans you can share regarding these revisions to the control > tools? I am exploring needs within my organization for management tools > on Xen. Besides being interested in what you have planned, I can > contribute assistance - development, testing, etc.Yes -- we have had a fair bit of discussion about this stuff over the past couple of months and there is even a bit of planning documention around somewhere. It''s the middle of the night in Cambridge though -- I''ll chat with people here tomorrow and aim to get some details posted either then or over the weekend. cheers, a. ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel