1

I have inherited the administration of a trusty ubuntu server with several virtual servers, also ubuntu using libvirt and qemu. I have the problem I cannot connect to these virtual servers/guests.

The root password was unknown of the physical box and so I had to recover this (which may have broken things) by using a Knoppix Live CD (as it handles both LVM2 and Raided disks/images) and did a chroot and changed password. Since then (coincidence?) the guests do not seem to have IP Addresses.

When I look at the 'ifconfig vnet0' output there is no IP Address assigned and the RX/TX count are 0. This seems in error (perhaps the virtual network bridge is bad or the guests are not running).

The virbr0 has an IP Address and the TX count increases when I try to ping an IP Address which should be assigned to vnet0. So the virtual network seems ok.

When I do 'virsh list --all' I see that the guests are running. I also see the processes with a 'ps -eaf | grep libvirt'. So the guests seem to exist. (But are they running?)

The 'shutdown' command does not shut down the guests. However, this may be valid (no apcid). The 'destroy' and 'start' work, but again not sure if the guests are running enough to get to the point of initialising network or not.

I tried to 'console GuestMachine' from within virsh, but this hung, I think I need to have getty running on guest machine.

The output of the ps also shows '-vnc 127.0.0.1:9'. However, all servers including the physical one do not have a GUI/X. I think VNC is only graphical and so that route is perhaps another dead end.

In '/var/log/libvirt/qemu/GuestMachine.log' there is nothing of note. I see the 'shutting down', 'starting up', command line options and 'char device redirected to /dev/pts/13 (label charserial0)'.

This is my first intro to libvirt and qemu, and after a bit of digging I am not sure if I have running guests or how to connect to them (without the IPAddress/ssh option).

Once I can connect to the guests, I am sure I can fix the IP Address issue, but without an IP Address I cannot connect to the guests.

In this situation is there a way to connect to guests?

Improve this question
3
  • The host's vnetX interfaces aren't supposed to have IP addresses. The IP addresses will be configured either in the guests themselves, or via DHCP.
    – womble ♦
    Sep 1, 2015 at 9:03
  • Thanks for this. I can see that the IP Address could be hidden so the host (server) does not see the guest IP Address, (although I think it is reasonable for the host to see this information). However, I would expect the TX/RX packet count to be visible? So if the guest sent a packet the host will see an increment to the count on that interface? (That information is like the bread and butter of solving network issues, along with burning hex digits into our retinas)
    – LazyBrush
    Sep 1, 2015 at 11:03
  • Use virt-manager.
    – Michael Hampton
    Sep 1, 2015 at 16:23

2 Answers 2

Reset to default
1

vnc is not limited to presenting a GUI; it can also present a graphical view of a shell prompt, just as you'd expect to see on the text console of a standalone box (eg, ALT-F2).

For example, here's me pointing a vnc viewer at the VNC port of one of my locally-hosted QEMU images:

enter image description here

It is, as you see, a non-GUI console, but I could happily log in here nonetheless, even if it had no IP address (as in fact it doesn't). Point your VNC viewer at port 5909 (add 5900 to the argument of -vnc 127.0.0.1:) and you should be fine.

Improve this answer
6
  • Thanks for this. So I don't have X running on the physical server, and so VNC Viewer complains. So I tried to run VNC Viewer on my desktop (OSX) and use 'ssh -v -L 5900:127.0.0.1:5900 myuser@GuestMachine' to do port forwarding. However, when I run VNC it flickers and exits. I see the port forwarding doing something. I also see that when I 'telnet 127.0.0.1 5900' on my desktop I see 'RFB 003.008' which makes me think the ssh part is probably working.
    – LazyBrush
    Sep 1, 2015 at 10:42
  • That is an entirely different problem. You need to be running X on the client where you run the VNC viewer; but you don't need to be running it on the VNC server that is thus viewed. Find somewehere you can run X and a VNC client, and do it from there. You will very likely also need to ssh-tunnel the connection as far as server, so run it from somewhere that has a good ssh client. A linux desktop would be ideal.
    – MadHatter
    Sep 1, 2015 at 10:43
  • Thanks for this. I've now used 2 VNC clients, the real vnc exits and the OSX Go->Connect to Server... then 'vnc://127.0.0.1:22590' just spins at the Connect step. (Note: On OSX to avoid the 'You cannot control your own screen', you need a large port number). So all this does (probably) point to my qemu guests not actually running.
    – LazyBrush
    Sep 1, 2015 at 12:05
  • Can you, on the qemu server, do telnet 127.0.0.1 5909 and get connection and some RFB ... output? If so, the guest you refer to in the question is running.
    – MadHatter
    Sep 1, 2015 at 12:41
  • Yes, 'telnet gets RFB string' on both the server and on my desktop (via the ssh tunnel), but using vnc on the desktop hangs/stops. Separately, on a different set of machines, I went through the connecting form OSX to a running linux (but with X) which worked a treat. But in that new scenario, I had to do various allow remote access config with vino-perferences. From all this I think either (1) My guests, although running might be stuck on linux boot and so seem dead to the world or (2) they are running and perhaps never having been ran with vnc might not have correct config.
    – LazyBrush
    Sep 1, 2015 at 14:07
0

As MadHatter stated the answer was to use VNC. However, with not having X on the server we need to use ssh to tunnel through to the guests.

ssh -v L 5901:127.0.0.1:5901 user@GuestMachine

When you connect (on the machine where you run ssh) to port 5901, it goes over the tunnel to GuestMachine and connect to port 5901 on loopback (on GuestMachine).

--

However, for me this did not work. The OSX built in VNC hung, and the RealVNC running on OSX exited ungracefully. This is where we dig deep and get Wireshark and start looking at packets.

I was not sure if OSX was doing something silly with firewall or some other clever manipulation, so I actually did the ssh on linux box. My full set up was then.

OSX(with VNC) ---Linux(with ssh)======Server(no GUI)--Guest(qemu)

On the Linux I traced the network packets, filter on OSX IP address or vnc to see the vnc packets.

The VNC RFB protocol was used to see that VNC had exited at the security stage with when using the default 'Let VNC Server choose' on VNC Viewer. I changed this to 'Prefer off' and although visually the same (exit ungracefully) there were more network packets.

Looking closer at the network packets. When server sent 'Server framebuffer parameters' and client sent 'Client set pixel format' (also 'client set encodings' and 'client frame buffer update request' both sides did a FIN/ACK.

Looking at these packets saw the Server asking for 'True colour flag:true' and the client had this as false. Back to VNC Viewer on OSX selecting 'Options...' and then 'Expert' scroll down to ColorLevel and change this from 'pal8' to 'full'.

After all this and I could connect with VNC to the guest! I could then see that the qemu guest was stuck on the GRUB screen. Being stuck at the boot loader was why there was no IP address. (But the reason for that is another question...)

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .