[libvirt] [PATCH] Introduce virt-console

John Levon john.levon at sun.com
Thu Jan 15 13:45:50 UTC 2009


On Thu, Jan 15, 2009 at 01:28:37PM +0000, Daniel P. Berrange wrote:

> > +libexec_PROGRAMS = virt-console
> 
> This can just be bin_PROGRAMS - not need to hide it outside of
> /usr/bin - its fine to let users just run virt-console directly
> if they wish

Solaris policy is not to introduce plumbing into the user's PATH.
virt-console is undocumented and there is no advantage to running it
directly. If it were in PATH we would have to document it, and we have
no intention of doing that...

> We need to add an explicit argument to turn on the automatic
> reconnect of VMs when they reboot. Existing apps calling
> virsh console rely on its current semantics which are to
> exit upon domain reboot and we can't break them

We argued about this last time. Looks like we'll have to keep this
change private, and let Linux users suffer. Oh well :)

> I'd suggest that when tracking across reboots, we should wait
> forever by default, and hav an optional timeout arg if you
> want to make it only wait 10 seconds.
> 
>    -r | --reconnect            reconnect when a VM reboots
>    -t | --timeout=N            exit if VM hasn't started after N seconds
> 
> Finally, if we're waiting after reboots, it seems sensible to
> also have the ability for wait for initial startup
> 
>    -w | --wait                 wait for VM to start if not running
> 
> That lets people launch virt-console before they start the VM
> for the first time, so they can catch initial mesages easily.

Sure.

> > +    if (tcgetattr(ttyfd, &ttyattr) < 0) {
> > +        ioctl(ttyfd, I_PUSH, "ptem");
> > +        ioctl(ttyfd, I_PUSH, "ldterm");
> > +        tcgetattr(ttyfd, &ttyattr);
> > +    }
> > +
> > +    cfmakeraw(&ttyattr);
> > +    tcsetattr(ttyfd, TCSANOW, &ttyattr);
> > +#endif
> 
> The caller of open_tty() is also doing the getattr/makeraw/setattr
> operation, so this block appears to be redundant - just need to

Nope, that's on STDIN, not the pty slave. Stupid STREAMS semantics.

regards
john




More information about the libvir-list mailing list