[libvirt] RFC: virt-console

See implementation here: http://cr.opensolaris.org/~johnlev/virt-console/ (inside libvirt.hg/patches/libvirt/virt-console) This splits virsh console into a separate binary to allow it to be setuid-root on Solaris (where we check permissions then drop privilege). It also fixes a number of RFEs This is against 0.4.0, so it's not ready for merging yet (I hope to get it forward ported at some point). regards john

On Tue, Jul 01, 2008 at 04:21:38PM +0100, John Levon wrote:
See implementation here:
http://cr.opensolaris.org/~johnlev/virt-console/
(inside libvirt.hg/patches/libvirt/virt-console)
Hum :-) ++ * Daniel Berrange <berrange@redhat.com> ++ * ++ * Copyright 2008 Sun Microsystems, Inc. All rights reserved.
This splits virsh console into a separate binary to allow it to be setuid-root on Solaris (where we check permissions then drop privilege). It also fixes a number of RFEs
This is against 0.4.0, so it's not ready for merging yet (I hope to get it forward ported at some point).
I may be mistaken but this seems to basically be limited to console for domains running on the local machine, and hum, I doubt it's really a good approach. Seems to me it's better to talk to the vnc (or other protocol used to connect remotely) export of the console, and get rid of the 'localhost only' limitation. But I may very well have missed something. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

On Tue, Jul 01, 2008 at 11:56:25AM -0400, Daniel Veillard wrote:
On Tue, Jul 01, 2008 at 04:21:38PM +0100, John Levon wrote:
See implementation here:
http://cr.opensolaris.org/~johnlev/virt-console/
(inside libvirt.hg/patches/libvirt/virt-console)
Hum :-)
++ * Daniel Berrange <berrange@redhat.com> ++ * ++ * Copyright 2008 Sun Microsystems, Inc. All rights reserved.
What?
This splits virsh console into a separate binary to allow it to be setuid-root on Solaris (where we check permissions then drop privilege). It also fixes a number of RFEs
This is against 0.4.0, so it's not ready for merging yet (I hope to get it forward ported at some point).
I may be mistaken but this seems to basically be limited to console for domains running on the local machine, and hum, I doubt it's really a good approach.
This is an incremental improvement over what exists in the current code (and indeed, is a partially a response to code review comments from Dan). It's not reasonable to expect me to go off and implement something else altogether (a remote console server). regards john

On Tue, Jul 01, 2008 at 05:49:34PM +0100, John Levon wrote:
On Tue, Jul 01, 2008 at 11:56:25AM -0400, Daniel Veillard wrote:
On Tue, Jul 01, 2008 at 04:21:38PM +0100, John Levon wrote:
See implementation here:
http://cr.opensolaris.org/~johnlev/virt-console/
(inside libvirt.hg/patches/libvirt/virt-console)
Hum :-)
++ * Daniel Berrange <berrange@redhat.com> ++ * ++ * Copyright 2008 Sun Microsystems, Inc. All rights reserved.
What?
Well I found that a bit strange, if Daniel Berrange wrote it I doubt the copyright would be Sun Microsystem, and vice-versa, maybe there is an author missing or something.
This splits virsh console into a separate binary to allow it to be setuid-root on Solaris (where we check permissions then drop privilege). It also fixes a number of RFEs
This is against 0.4.0, so it's not ready for merging yet (I hope to get it forward ported at some point).
I may be mistaken but this seems to basically be limited to console for domains running on the local machine, and hum, I doubt it's really a good approach.
This is an incremental improvement over what exists in the current code (and indeed, is a partially a response to code review comments from Dan). It's not reasonable to expect me to go off and implement something else altogether (a remote console server).
okay, I wasn't sure it was the plan and I was asking. As Dan pointed out it's the right approach, okay, I'm just surprized. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

On Tue, Jul 01, 2008 at 01:52:01PM -0400, Daniel Veillard wrote:
See implementation here:
http://cr.opensolaris.org/~johnlev/virt-console/
(inside libvirt.hg/patches/libvirt/virt-console)
Hum :-)
++ * Daniel Berrange <berrange@redhat.com> ++ * ++ * Copyright 2008 Sun Microsystems, Inc. All rights reserved.
What?
Well I found that a bit strange, if Daniel Berrange wrote it I doubt the copyright would be Sun Microsystem, and vice-versa, maybe there is an author missing or something.
Dan wrote the original code, and I made significant changes. Thus, Dan's copyright and author comment, followed by Sun's. Sun, as a matter of policy, don't include author information in source code. If there's some clearer way of doing this you can think of, let me know.
Dan). It's not reasonable to expect me to go off and implement something else altogether (a remote console server).
okay, I wasn't sure it was the plan and I was asking. As Dan pointed out it's the right approach, okay, I'm just surprized.
To be clear, we'd love to see a remote console implementation happen, it's just not a priority for us right now. regards, john

On Tue, Jul 01, 2008 at 07:00:51PM +0100, John Levon wrote:
On Tue, Jul 01, 2008 at 01:52:01PM -0400, Daniel Veillard wrote:
See implementation here:
http://cr.opensolaris.org/~johnlev/virt-console/
(inside libvirt.hg/patches/libvirt/virt-console)
Hum :-)
++ * Daniel Berrange <berrange@redhat.com> ++ * ++ * Copyright 2008 Sun Microsystems, Inc. All rights reserved.
What?
Well I found that a bit strange, if Daniel Berrange wrote it I doubt the copyright would be Sun Microsystem, and vice-versa, maybe there is an author missing or something.
Dan wrote the original code, and I made significant changes. Thus, Dan's copyright and author comment, followed by Sun's. Sun, as a matter of policy, don't include author information in source code. If there's some clearer way of doing this you can think of, let me know.
Just move the Copyright statement up a few lines in the source file so its directly below the existing Copyright statement in the file.
Dan). It's not reasonable to expect me to go off and implement something else altogether (a remote console server).
okay, I wasn't sure it was the plan and I was asking. As Dan pointed out it's the right approach, okay, I'm just surprized.
To be clear, we'd love to see a remote console implementation happen, it's just not a priority for us right now.
Newer QEMU also supports the 'telnet' protocol, so we might be better off just telling people to use a telnet client, and keep this for local only PTY based console access. Of course you're using Xen with libvirt, so it'd probably require Xen to port to the newer QEMU codebase before that's an option for you. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

On Tue, Jul 01, 2008 at 07:14:04PM +0100, Daniel P. Berrange wrote:
okay, I wasn't sure it was the plan and I was asking. As Dan pointed out it's the right approach, okay, I'm just surprized.
To be clear, we'd love to see a remote console implementation happen, it's just not a priority for us right now.
Newer QEMU also supports the 'telnet' protocol, so we might be better off just telling people to use a telnet client, and keep this for local only PTY based console access.
Indeed, this is what we're doing for debugging purposes, and it already works (for HVM only). But of course it's not secure yet, so it's really no better than just sshing to run virsh console locally. regards john

On Tue, Jul 01, 2008 at 07:26:44PM +0100, John Levon wrote:
On Tue, Jul 01, 2008 at 07:14:04PM +0100, Daniel P. Berrange wrote:
okay, I wasn't sure it was the plan and I was asking. As Dan pointed out it's the right approach, okay, I'm just surprized.
To be clear, we'd love to see a remote console implementation happen, it's just not a priority for us right now.
Newer QEMU also supports the 'telnet' protocol, so we might be better off just telling people to use a telnet client, and keep this for local only PTY based console access.
Indeed, this is what we're doing for debugging purposes, and it already works (for HVM only). But of course it's not secure yet, so it's really no better than just sshing to run virsh console locally.
I've no idea just how much work it'd be, but IIRC there is a telnet extension to layer in Kerberos for both auth & session encryption. Might be something to think about in the future, since it'd allow secure console access without having to give out a shell account on the host machine Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

On Tue, Jul 01, 2008 at 11:56:25AM -0400, Daniel Veillard wrote:
On Tue, Jul 01, 2008 at 04:21:38PM +0100, John Levon wrote:
See implementation here:
http://cr.opensolaris.org/~johnlev/virt-console/
(inside libvirt.hg/patches/libvirt/virt-console)
Hum :-)
++ * Daniel Berrange <berrange@redhat.com> ++ * ++ * Copyright 2008 Sun Microsystems, Inc. All rights reserved.
This splits virsh console into a separate binary to allow it to be setuid-root on Solaris (where we check permissions then drop privilege). It also fixes a number of RFEs
This is against 0.4.0, so it's not ready for merging yet (I hope to get it forward ported at some point).
I may be mistaken but this seems to basically be limited to console for domains running on the local machine, and hum, I doubt it's really a good approach. Seems to me it's better to talk to the vnc (or other protocol used to connect remotely) export of the console, and get rid of the 'localhost only' limitation. But I may very well have missed something.
This is the same limitation as the existing 'virsh console' - John's merely splitting it into a separate binary, which is what I previously suggested for making the solaris privilege separation work better in the context of virsh. It is also only intended to be used for the text console - we've already got perfectly good clients for the remote graphical VNC console. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

On Tue, Jul 01, 2008 at 04:21:38PM +0100, John Levon wrote:
See implementation here:
http://cr.opensolaris.org/~johnlev/virt-console/
(inside libvirt.hg/patches/libvirt/virt-console)
This splits virsh console into a separate binary to allow it to be setuid-root on Solaris (where we check permissions then drop privilege). It also fixes a number of RFEs
--- libvirt-0.4.0/src/Makefile.in 2008-06-27 06:17:20.865621099 -0700 +++ libvirt-1/src/Makefile.in 2008-06-27 06:19:55.983265305 -0700
You can exclude Makefile.in from patches, since its auto-generated.
--- libvirt-0.4.0/src/virsh.c 2008-06-27 13:30:32.395824295 -0700 +++ libvirt-new/src/virsh.c 2008-06-27 13:29:26.021985284 -0700 @@ -48,7 +48,7 @@ #endif
#include "internal.h" -#include "console.h" +#include "util.h"
static char *progname; static int sigpipe; @@ -446,7 +446,7 @@ cmdConnect(vshControl * ctl, vshCmd * cm * "console" command */ static vshCmdInfo info_console[] = { - {"syntax", "console <domain>"}, + {"syntax", "console [--verbose] <domain>"}, {"help", gettext_noop("connect to the guest console")}, {"desc", gettext_noop("Connect the virtual serial console for the guest")}, @@ -454,6 +454,7 @@ static vshCmdInfo info_console[] = { };
static vshCmdOptDef opts_console[] = { + {"verbose", VSH_OT_BOOL, 0, gettext_noop("verbose console")}, {"domain", VSH_OT_DATA, VSH_OFLAG_REQ, gettext_noop("domain name, id or uuid")}, {NULL, 0, 0, NULL} }; @@ -463,50 +464,37 @@ static vshCmdOptDef opts_console[] = { static int cmdConsole(vshControl * ctl, vshCmd * cmd) { - xmlDocPtr xml = NULL; - xmlXPathObjectPtr obj = NULL; - xmlXPathContextPtr ctxt = NULL; - virDomainPtr dom; + int verbose = vshCommandOptBool(cmd, "verbose"); + char *argv[] = { "/usr/bin/virt-console", NULL, NULL, NULL, NULL };
This should probably be char *argv[] = { BINDIR "/virt-console", NULL, NULL, NULL, NULL }; so that it auto-adjusts when people pass --prefix to configure
- obj = xmlXPathEval(BAD_CAST "string(/domain/devices/console/@tty)", ctxt); - if ((obj != NULL) && ((obj->type == XPATH_STRING) && - (obj->stringval != NULL) && (obj->stringval[0] != 0))) { - if (vshRunConsole((const char *)obj->stringval) == 0) - ret = TRUE; - } else { - vshPrintExtra(ctl, _("No console available for domain\n")); + ret = virExecNoPipe(ctl->conn, argv, &pid); + if (ret == -1) { + vshError(ctl, FALSE, _("Couldn't execute /usr/bin/virt-console.")); + return FALSE; } - xmlXPathFreeObject(obj);
- cleanup: - if (ctxt) - xmlXPathFreeContext(ctxt); - if (xml) - xmlFreeDoc(xml); - virDomainFree(dom); - return ret; + waitpid(pid, NULL, 0);
Ought to do this in a while loop to handle EINTR.
--- /dev/null 2008-06-30 17:03:12.000000000 -0700 +++ libvirt-new/src/virt-console.c 2008-06-30 16:58:36.079071463 -0700
I'd prefer to keep the source in the 'console.c' file instead of renaming it, just to make historical diff tracking a little easier.
+#include "internal.h" + +/* ie Ctrl-] as per telnet */ +#define CTRL_CLOSE_BRACKET '\35' + +static int got_signal; +static int verbose; +static const char *dom_name; +static const char *conn_name; + +static void +do_signal(int sig ATTRIBUTE_UNUSED) +{ + got_signal = 1; +} + +#ifndef HAVE_CFMAKERAW +static void +cfmakeraw(struct termios *attr) +{ + attr->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP + | INLCR | IGNCR | ICRNL | IXON); + attr->c_oflag &= ~OPOST; + attr->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); + attr->c_cflag &= ~(CSIZE | PARENB); + attr->c_cflag |= CS8; + +#ifdef __sun + attr->c_cc[VMIN] = 0; + attr->c_cc[VTIME] = 0; +#endif +} +#endif /* !HAVE_CFMAKERAW */
A question for Jim here ... does gnulib have a cfmakeraw() implementation we can use ?
+static int +get_domain(virConnectPtr *conn, virDomainPtr *dom, + virDomainInfo *info, int lookup_by_id) +{ + int ret = 0; + int id; + + __priv_bracket(PRIV_ON); + + *conn = virConnectOpenAuth(conn_name, virConnectAuthPtrDefault, 0);
We ought to pass VIR_CONNECT_RO as the 3rd arg here, since the console doesn't require write access.
+ if (*conn == NULL) { + fprintf(stderr, _("Failed to connect to the hypervisor")); + exit(EXIT_FAILURE); + } + + *dom = virDomainLookupByName(*conn, dom_name); + + if (*dom == NULL) + *dom = virDomainLookupByUUIDString(*conn, dom_name); + if (*dom == NULL && lookup_by_id && + xstrtol_i(dom_name, NULL, 10, &id) == 0 && id >= 0)
Can use virStrToLong_i from util.h here.
+ obj = xmlXPathEval(BAD_CAST "string(/domain/devices/console/@tty)", ctxt);
The virXPathString() method from xml.h will simplify the following handling
+ if (obj == NULL) + goto cleanup; + if (obj->type != XPATH_STRING) + goto cleanup; + if (!obj->stringval || obj->stringval[0] == '\0') + goto cleanup; + + tty = strdup((const char *)obj->stringval); + +cleanup: + if (obj != NULL) + xmlXPathFreeObject(obj); + free(doc); + if (ctxt != NULL) + xmlXPathFreeContext(ctxt); + if (xml != NULL) + xmlFreeDoc(xml); + return tty; +}
+static int +check_for_reboot(void) +{ + virConnectPtr conn = NULL; + virDomainPtr dom = NULL; + virDomainInfo info; + int tries = 0; + int ret = 0; + +retry: + if (dom != NULL) + put_domain(conn, dom); + + /* + * Domain ID will vary across reboot, so don't lookup by a given ID. + */ + if (!get_domain(&conn, &dom, &info, 0)) + return 0; + + switch (info.state) { + case VIR_DOMAIN_RUNNING: + case VIR_DOMAIN_BLOCKED: + case VIR_DOMAIN_PAUSED: + ret = 1; + goto out; + break; + + case VIR_DOMAIN_CRASHED: + if (verbose) + fprintf(stderr, _("Domain \"%s\" has crashed."), dom_name); + goto out; + break; + + case VIR_DOMAIN_NOSTATE: + default: + break; + + case VIR_DOMAIN_SHUTDOWN: + if (verbose) + fprintf(stderr, _("Domain \"%s\" is shutting down.\n"), dom_name); + tries = 0; + break; + + case VIR_DOMAIN_SHUTOFF: + if (verbose) + fprintf(stderr, _("Domain \"%s\" has shut down."), dom_name); + goto out; + break; + } + + tries++; + if (tries == 1) { + goto retry; + } else if (tries == 2) { + sleep(1); + goto retry; + }
I think we probably need to wait a little longer than this - 5 times with a 1 second sleep perhaps. Under heavy load it can take a while for reboot to complete
+ +out: + put_domain(conn, dom); + return ret; +} + +static int +open_tty(void) +{ + char *tty; + int ttyfd; + + if ((tty = get_domain_tty()) == NULL) { + if (domain_is_running() != 1) { + fprintf(stderr, _("Domain \"%s\" is not running.\n"), dom_name); + exit(EXIT_FAILURE); + } + + fprintf(stderr, + _("Couldn't get console for domain \"%s\"\n"), dom_name); + exit(EXIT_FAILURE); + } + + __priv_bracket(PRIV_ON); + if ((ttyfd = open(tty, O_NOCTTY | O_RDWR)) < 0) { + fprintf(stderr, _("Unable to open tty %s: %s\n"), + tty, strerror(errno)); + exit(EXIT_FAILURE); + } + + if (lockf(ttyfd, F_TLOCK, 0) == -1) {
Ahh good idea to lock the tty.
+ if (errno == EACCES || errno == EAGAIN) { + fprintf(stderr, + _("Console for domain \"%s\" is in use.\n"), dom_name); + } else { + fprintf(stderr, _("Unable to lock tty %s: %s\n"), + tty, strerror(errno)); + } + exit(EXIT_FAILURE); + } + __priv_bracket(PRIV_OFF); + + free(tty);
When forward porting you can use VIR_FREE, from memory.h
+retry: + + ttyfd = open_tty(); + + if (!retrying && verbose) { + printf("Connected to domain %s\n", dom_name); + printf("Escape character is '^]'\n"); + } + + if (tcgetattr(STDIN_FILENO, &ttyattr) < 0) { + fprintf(stderr, _("Unable to get tty attributes: %s\n"), + strerror(errno)); + exit(EXIT_FAILURE); + } + + rawattr = ttyattr; + cfmakeraw(&rawattr); + + if (tcsetattr(STDIN_FILENO, TCSAFLUSH, &rawattr) < 0) { + fprintf(stderr, _("Unable to set tty attributes: %s\n"), + strerror(errno)); + exit(EXIT_FAILURE); + } + + /* Now lets process STDIN & tty forever.... */ + for (; !got_signal ;) { + unsigned int i; + struct pollfd fds[] = { + { STDIN_FILENO, POLLIN, 0 }, + { ttyfd, POLLIN, 0 }, + }; + + /* Wait for data to be available for reading on + STDIN or the tty */ + if (poll(fds, (sizeof(fds)/sizeof(struct pollfd)), -1) < 0) { + if (got_signal) + goto cleanup; + + if (errno == EINTR || errno == EAGAIN) + continue; + + fprintf(stderr, _("Failure waiting for I/O: %s\n"), + strerror(errno)); + goto cleanup; + } + + for (i = 0 ; i < (sizeof(fds)/sizeof(struct pollfd)) ; i++) { + if (!fds[i].revents) + continue; + + /* Process incoming data available for read */ + if (fds[i].revents & POLLIN) { + char buf[4096]; + int got, sent = 0, destfd; + + if ((got = read(fds[i].fd, buf, sizeof(buf))) < 0) { + fprintf(stderr, _("Failure reading input: %s\n"), + strerror(errno)); + goto cleanup; + } + + if (!got) { + tcsetattr(STDIN_FILENO, TCSAFLUSH, &ttyattr); + if (!check_for_reboot()) + goto done; + close_tty(ttyfd); + retrying = 1; + goto retry; + } + + if (got == 1 && buf[0] == CTRL_CLOSE_BRACKET) + goto done; + + /* Data from stdin goes to the TTY, + data from the TTY goes to STDOUT */ + if (fds[i].fd == STDIN_FILENO) + destfd = ttyfd; + else + destfd = STDOUT_FILENO; + + while (sent < got) { + int done; + if ((done = write(destfd, buf + sent, got - sent)) <= 0) { + fprintf(stderr, _("Failure writing output: %s\n"), + strerror(errno)); + goto cleanup; + } + sent += done; + } + } else if (fds[i].revents & POLLHUP) { + tcsetattr(STDIN_FILENO, TCSAFLUSH, &ttyattr); + if (!check_for_reboot()) + goto done;
I like the support for re-connecting after reboot. At the same time I wonder if we need to make the an optional command line flag. Some apps using virsh console, may rely on the fact that it exits when a VM shuts down. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

On Tue, Jul 01, 2008 at 07:35:56PM +0100, Daniel P. Berrange wrote:
http://cr.opensolaris.org/~johnlev/virt-console/
--- libvirt-0.4.0/src/Makefile.in 2008-06-27 06:17:20.865621099 -0700 +++ libvirt-1/src/Makefile.in 2008-06-27 06:19:55.983265305 -0700
You can exclude Makefile.in from patches, since its auto-generated.
Yes, I know, but not for our bits (long story, hopefully fixed soon).
+ char *argv[] = { "/usr/bin/virt-console", NULL, NULL, NULL, NULL };
This should probably be
char *argv[] = { BINDIR "/virt-console", NULL, NULL, NULL, NULL };
so that it auto-adjusts when people pass --prefix to configure
Sure.
+ waitpid(pid, NULL, 0);
Ought to do this in a while loop to handle EINTR.
OK, although I'm not sure it really matters here?
--- /dev/null 2008-06-30 17:03:12.000000000 -0700 +++ libvirt-new/src/virt-console.c 2008-06-30 16:58:36.079071463 -0700
I'd prefer to keep the source in the 'console.c' file instead of renaming it, just to make historical diff tracking a little easier.
Really? Surely even subversion can do cross-rename tracking OK?
+ *conn = virConnectOpenAuth(conn_name, virConnectAuthPtrDefault, 0);
We ought to pass VIR_CONNECT_RO as the 3rd arg here, since the console doesn't require write access.
OK.
The virXPathString() method from xml.h will simplify the following handling Can use virStrToLong_i from util.h here.
The perils of borrowing code, everyone wants to clean it up. Sure :)
I think we probably need to wait a little longer than this - 5 times with a 1 second sleep perhaps. Under heavy load it can take a while for reboot to complete
Yeah, you might be right. Though it's possible to break even this most likely.
I like the support for re-connecting after reboot. At the same time I wonder if we need to make the an optional command line flag. Some apps using virsh console, may rely on the fact that it exits when a VM shuts down.
I hate --behave-like-you-should flags and will do everything I can to avoid them. Let's not inconvenience everybody for the sake of some possible breakage. The perils of people coding to human interfaces. (I wanted to make --verbose the default, like telnet, but that seemed much more likely to break someone's scripts). I'm not adverse to a disconnect-on-shutdown flag, if people think it would be useful, which would at least make any such breakage that might exist easy to fix. Thanks for the review Dan. regards, john

On Tue, Jul 01, 2008 at 07:50:02PM +0100, John Levon wrote:
On Tue, Jul 01, 2008 at 07:35:56PM +0100, Daniel P. Berrange wrote:
--- /dev/null 2008-06-30 17:03:12.000000000 -0700 +++ libvirt-new/src/virt-console.c 2008-06-30 16:58:36.079071463 -0700
I'd prefer to keep the source in the 'console.c' file instead of renaming it, just to make historical diff tracking a little easier.
Really? Surely even subversion can do cross-rename tracking OK?
We're using CVS for libvirt & yes it sucks :-)
I like the support for re-connecting after reboot. At the same time I wonder if we need to make the an optional command line flag. Some apps using virsh console, may rely on the fact that it exits when a VM shuts down.
I hate --behave-like-you-should flags and will do everything I can to avoid them. Let's not inconvenience everybody for the sake of some possible breakage. The perils of people coding to human interfaces. (I wanted to make --verbose the default, like telnet, but that seemed much more likely to break someone's scripts).
I'm mostly concerned about 'virsh console' - we only need to keep compatability for that. The standalone virt-console can have the auto-track restarts syntax and we can recommend use for virt-console as the primary tool, just having virsh console for compat. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

On Tue, Jul 01, 2008 at 08:02:03PM +0100, Daniel P. Berrange wrote:
I hate --behave-like-you-should flags and will do everything I can to avoid them. Let's not inconvenience everybody for the sake of some possible breakage. The perils of people coding to human interfaces. (I wanted to make --verbose the default, like telnet, but that seemed much more likely to break someone's scripts).
I'm mostly concerned about 'virsh console' - we only need to keep compatability for that. The standalone virt-console can have the auto-track restarts syntax and we can recommend use for virt-console as the primary tool, just having virsh console for compat.
Hmm, I'm not sure that's much of an improvement. Currently virsh is a great one-stop shop for managing instances, it would be a shame if we had to break that. Fundamentally I don't believe that virsh console was ever a stable interface to program to. Given that it goes to the domain console, how could it be? The output of the domain on the console is surely not stable. (In Solaris land, we deal with this by explicitly documenting stability of output and such; it's very much a shame that the wider UNIX community never picked up on this.) regards john
participants (3)
-
Daniel P. Berrange
-
Daniel Veillard
-
John Levon