Hi, this question may be better on the users-list (or cross-post), but anyway: First off, there is some key-combination to make up a xen-console (or switch them?)? If yes, what is it again ^^? Anyway, the thing is that we have/maintain userspace-tools, which depend on python *and* (currently?) on Twisted (which is a mess to set-up, imho), but we *could* do it in a more general way. If we already have code to catch certain keyboard events, like ctrl+a three times (is this the answer to question one?), what about a internal xen command line? The idea that we offer an API to administrate the Xen-host (create/destroy domains, change their memory usage, and whatnot) is a very good thing. Now the best thing would be if the user could press ctrl+escape (imaginary key combination) three times, and Xen switches to some console and display a xen> prompt (or whatever), and the user can do everything we normally do with xm(...), making user-space tools totally obsolete. At this point, we 1.) would not have to maintain user-space tools anymore. If the API changes, we just adjust the Documentation and our internal prompt. 2.) don''t have to care about dom0. Be it Linux, *BSD, be it an OS where python does not run on, etc. Topic 2 is of course more problematic... what if a graphical system is fired up? How do we switch to a textural console? I don''t know VGA (or even others) enough to answer this question, I''d assume the best way would be to inform the dom0 to switch to textmode (and back). Comments? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> First off, there is some key-combination to make up a xen-console (or > switch them?)? If yes, what is it again ^^?What exactly do you mean by this?> if the user could press ctrl+escape (imaginary key combination) three > times,There''s no place like home, there''s no place like home, there''s no place like home.> At this point, we > 1.) would not have to maintain user-space tools anymore. If the API > changes, we just adjust the Documentation and our internal prompt.No, we still need to maintain user-space tools. What if the admin wants to start a domain every night at 1800 and shut it down again at 1830? We implement cron in our mini-console? What about when he wants to use a web-frontend? What about if he wants to extend the web-frontend so that people who are hiring domains in his server can perform actions on them without having to bother him continually?> 2.) don''t have to care about dom0. Be it Linux, *BSD, be it an OS > where python does not run on, etc.We still need to care about dom0. Dom0 still runs the backend drivers for the VIFs and VBDs, and still has special privileges to talk to the hardware. We also: 3.) have a ridiculously large Xen hypervisor 4.) have no way of attracting the admin''s attention when we want it 5.) need the admin to be at console to do things rather than just ssh''ing into dom0 6.) start and stop domains in a different place to where we start and stop the virtual devices we are offering them Any one of these is a showstopper. -- "And what if I assign a hundred programmers to it?" The master programmer shrugged. "Then the design will never be completed," he said. http://www.google.com/search?q=%22pgp+singing%22 <-- childish but funny http://surreal.istic.org/ <-- It''s like a DEATH CIRCUS! | keyid 885b170d _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel