I always forget how to do this, but in fact it’s quite simple.
First ensure your libvirt XML contains a fragment like this (my guest, installed using virt-install, already had this).
Second, edit /boot/grub/grub.conf inside the guest, adding the console=ttyS0 element to the kernel command line:
# virt-edit Guestname /boot/grub/grub.conf ... title Fedora (2.6.38.6-26.rc1.fc15.x86_64) root (hd0,0) kernel /vmlinuz ro [...] console=ttyS0 ...
You don’t need to set the speed. I believe it defaults to 115200 8N1, but I don’t think that qemu serial ports have a “speed” as such, since the hardware is emulated.
Third, start the guest and dump out the running XML:
# virsh start Guestname && virsh dumpxml Guestname
...
<console type='pty' tty='/dev/pts/8'>
Notice the randomly assigned pty on the host side (/dev/pts/8). Connect to that with Minicom[1], and you should see boot messages and/or a login prompt.
[1] Is there something better than minicom? It’s a horrible program, always has been.
Yes: screen /dev/ttyUSB0 115200
Richard WM Jones 
You can use `cu` or `screen` instead of `minicom`.
What about just using:
virsh console guestname
Nice post!!
There’s also ‘virsh console $guestname’
Also virsh provides a helper to skip the parsing step as well
$ virsh ttyconsole serial-test
/dev/pts/1
And if your guest doesn’t have any serial/console device configured for any reason, the easiest way is to just add to the block in the XML (or use virt-manager 😀 )
I’ve heard that KVM has equivalent functionality to VMware’s vmotion, in which a live client gets moved from one host to another. With VMware, a guest having a virtual serial device like this prevented it from participating in vmotion (that may have changed over the last year, but I haven’t heard). How is a serial line handled when re-hosting a KVM running client? And if you could recommend a tutorial on setting up live KVM guest rehosting, I’d be grateful.
The way qemu live migration works is this: You[*] set up an empty container qemu instance on the target server, configured identically to the source qemu. So block devices, serial ports etc on the target are initialized by you and have to have the same configuration as the source. You then send a message to the source qemu telling it to start migration. This causes the source qemu to serialize the whole internal state (memory + device state) and send it to the target, usually over a TCP connection, although qemu migration is transport independent.
This is a good summary of the technical details.
So the answer to your first question is just that the management tool sets up another serial port and has to deal with how it is connected. libvirt does a few clever things in this area already, with more to come.
Second question about “live KVM guest rehosting” I wasn’t quite sure what that means. For setting up an environment where you can migrate, load balance etc. you need some higher level tool like RHEV-M.
[*] “You” in this instance usually means some management tool, ie.
libvirtd, although I guess you could do this by hand if you were a certain sort of masochist.Thanks! Out of ignorance I used the phrase “live KVM guest rehosting” to mean exactly the migration you describe and which the link you referenced describes.
yeah minicom sux. use tip(1) or cu(1).
-Alex
Thanks for the “tip” (ba-bum tish …)
I do not share your aversion to minicom — probably from too many hours remotely configuring Cisco kit across serial links. But, that said, and if one favors a GUI environment, the ‘putty’ program has a serial console mode, and is available in open source form, and on Linux, OS/X, and Windows
— Russ herrold
Agreed. IMHO Putty is far better. Putty is useful, even under Linux. It makes using the advanced settings of ssh, ones that would typically require a seperate config file, much easier. (Keep Alive, sock5 proxy, etc)
You can also get the “console=ttyS0″ in grub with a kickstart line like bootloader –location=mbr –append=”rhgb quiet console=ttyS0”
Are tip(1) or cu(1) in RHEL or Fedora? Those short names are hard to search for.
Also, is there a mailing list for libvirt/guestfish/etc?
Sadly neither tip nor cu are in Fedora. You can search for packages in Fedora by modifying this URL:
https://admin.fedoraproject.org/pkgdb/acls/list/cu*
The libvirt mailing lists are listed here.
The libguestfs mailing list and IRC channel are linked from the website, on the right hand side, under “Mailing list and chat”.
Note that the easiest way to answer the `is command in Fedora` is to simply run `dnf install /usr/bin/` (this also works with yum). For the `cu` program, this ends up installing the “uucp” package, which includes the “cu” binary.
And how can I connect together two VMs with serial port? For example testing a PPP connection?
I tried to setup a unix socket with virt-manager under Ubuntu 12.04 and it complains about permissions. If I created manually the socket with mkfifo command the complains was changed to Address already used.
And what about vc or any other possibilities (TCP/UDP)?
Is there a HowTo somewhere about that serial communication setup in qemu (or even in virt-manager)?
TIA,
I get the following message on virt-edit Guestname /boot/grub/grub.conf.
I have executed the command.
guestmount –ro -a /var/lib/nova/instances/instance-00000001/disk -m /dev/sda1 /mnt
guestmount -d instance-00000001 -i –ro /mnt
root@compute:~# virt-edit instance-00000001 /boot/grub/grub.conf
libguestfs: error: error: domain is a live virtual machine.
Writing to the disks of a running virtual machine can cause disk corruption.
Either use read-only access, or if the guest is running the guestfsd daemon
specify live access. In most libguestfs tools these options are –ro or
–live respectively. Consult the documentation for further information.
root@compute:~#
Please help how to get past this.
This isn’t the place to ask for libguestfs help. Use the libguestfs mailing list. In any case, if you read the error message, it tells you what to do.
Hello! ‘cu’ can be found in the ‘uucp’ package (“yum provides */cu”). Your blog has always been a great source of information on virtualization, even though I am running Fedora 19, and as a consequence, a bit behind in what is available.
You can also get grub itself to present its menu over the serial port (as well as via VGA at the same time)
Add the following lines to grub.cfg
serial –speed=115200 –unit=0 –word=8 –parity=no –stop=1
terminal_input serial console
terminal_output serial console
– on Debian, Ubuntu etc. add these lines to /etc/default/grub
GRUB_TERMINAL=”serial console”
GRUB_SERIAL_COMMAND=”serial –speed=115200 –unit=0 –word=8 –parity=no –stop=1″
and then run update-grub to get the same effect…
Thanks Tim.
Thanks Tim!
Linux console settings should also go to /etc/default/grub on modern distros, otherwise they won’t be persistent on kernel updates.
This one would set console device for recovery and normal mode:
GRUB_CMDLINE_LINUX=”console=ttyS0″
Serial console can also be setup in QEMU bios with 3s boot menu timeout:
…
Hi Richard, I have a proprietary guest, I cannot edit files there. And I have virt-manager on the host. Could you please provide some details on how to access the guest via serial from the host?
Your help would be really appreciated.
Since I keep on stumbling on this post when I do a web search for “kvm enable serial console”, but miss a few steps.The full procedure for me is:
* virt-edit $host /boot/grub2/grub.conf
* Add “console=ttyS0” to the “linux” line for the appropriate menuentry.
* virsh console $guest
* guest# systemctl enable serial-getty@ttyS0.service
* guest# vi /etc/default/grub
* Add “console=ttyS0” to theGRUB_CMDLINE_LINUX variable definition.
* guest# grub2-mkconfig -o /boot/grub2/grub.conf
The first line should be “virt-edit $guest /boot/grub2/grub.conf”, instead. Sorry about that.