<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi All,<div><br></div><div>I could following documentation , </div><div><a href="https://wiki.libvirt.org/page/LibvirtConsoleManagement">https://wiki.libvirt.org/page/LibvirtConsoleManagement</a> <br></div><div>I hope this doc is upto date , as of now there is no way other than conserver. Please let me know if there is any alternative.</div><div><h1 id="gmail-firstHeading" class="gmail-firstHeading" lang="en" style="color:rgb(0,0,0);background-image:none;margin:0em 0px 0.1em;overflow:hidden;padding:0px;border:0px;line-height:1.2em;font-family:LibvirtOverpass"><font size="2">LibvirtConsoleManagement (doc snippet pasted from above link)</font></h1></div><div>----------------------------------------------------------</div><div><span style="color:rgb(0,0,0);font-family:LibvirtOverpass;font-size:14px">This page describes an approach to managing virtual machine text consoles, which leverages the conserver daemon</span></div><div><h2 style="color:rgb(0,0,0);background-image:none;margin:1em 0px 0.25em;overflow:hidden;padding:0px;border:0px;font-size:1.4em;font-family:LibvirtOverpass"><span class="gmail-mw-headline" id="gmail-Background_information">Background information</span></h2><p style="color:rgb(0,0,0);margin:1em 0px;padding:0px;font-family:LibvirtOverpass;font-size:14px">With Xen, LXC, KVM, etc hypervisors there is typically a serial console or a paravirtualized log for each virtual machine. Typically this is exposed on the host as a dynamically allocated psuedo TTY, but they can also be configured to use a UNIX or TCP socket, a FIFO pipe or (output only) to a plain file.</p><p style="color:rgb(0,0,0);margin:1em 0px;padding:0px;font-family:LibvirtOverpass;font-size:14px">The consoles are typically used as a text-mode interactive shell, or to log all guest console messages, or both. There are a number of limitations with the console functionality that is exposed natively by the hypervisors</p><ul style="color:rgb(0,0,0);margin:0.3em 0px 0px 1.6em;padding:0px;font-family:LibvirtOverpass;font-size:14px"><li style="margin-bottom:0.1em">It is impossible to configure a console to both provide an interactive pTTY, and log all data to a file concurrently.</li><li style="margin-bottom:0.1em">If configured to log to a file, the file will grow without any bounds</li><li style="margin-bottom:0.1em">The console TTY names are unstable across restarts of the virtual machine, since they are dynamically allocated by the host kernel</li><li style="margin-bottom:0.1em">The console TTYs only exist while the VM is running</li><li style="margin-bottom:0.1em">There is typically no native, secure, remote TCP access</li></ul><h2 style="color:rgb(0,0,0);background-image:none;margin:1em 0px 0.25em;overflow:hidden;padding:0px;border:0px;font-size:1.4em;font-family:LibvirtOverpass"><span class="gmail-mw-headline" id="gmail-Architecture_design">Architecture design</span></h2><p style="color:rgb(0,0,0);margin:1em 0px;padding:0px;font-family:LibvirtOverpass;font-size:14px">The problems described with the native hypervisor console configuration can broadly be addressed by leveraging the conserver daemon, which is distributed as a standard part of most Linux distributions. The main integration pain point is that the conserver daemon uses a static configuration file, while virtual machines can come & go at any moment. </p><p style="color:rgb(0,0,0);margin:1em 0px;padding:0px;font-family:LibvirtOverpass;font-size:14px">There is a need, therefore, to have a way of automatically generating/updating the conserver configuration file on the fly to deal with dynamic virtual machines. This can be achieved by having a process which listens out for libvirt domain lifecycle events and triggers an update of the conserver configuration file at appropriate times.</p></div><div><br></div><div>Regards</div><div>Gokul </div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 11, 2019 at 12:20 PM gokul cg <<a href="mailto:gokuljnpr@gmail.com">gokuljnpr@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>+dev<br></div>Hi Folks ,<br><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>As per <a href="https://libvirt.org/formatdomain.html#elementsConsole" target="_blank">https://libvirt.org/formatdomain.html#elementsConsole</a> </div><div>Regardless of the type, character devices can have an optional log file associated with them. <br></div><div><div>Whether the lgging functionality is same as mapping device to file ?</div><div>Whether libvirt xml syntax below both 1 and 2 are same ?</div><div><br></div><div> 1)</div><div> <serial type='pty'></div><div> <log file='/var/lib/nova/instances/7151c8b7-1ea5-4701-bb79-b482d9e253b8/console.log' append='off'/></div><div> <target port='0'/></div><div> </serial></div><div><br></div><div> 2)</div><div> <serial type='pty'></div><div> <source path='/tmp/serial.log'/></div><div> <target port='0'/></div><div> </serial></div><div><br></div><div> is it possible to multiplex the output from qemu's serial port to a pty as well as a file (basically redirect console to file as well as pty device)?</div><div><br></div><div>Regards</div><div>Gokul</div><div><br></div></div></div></div></div> </div></div> </div></div> </blockquote></div>