How to get Virtual Manager to work for a Xen host

So, continuing with the theme of Xen, Virtual Machine Manager or virt-manager for short, is a piece of software that I decided to check out because I wanted graphical access to my virtual machines. A more formal description as given on their website is:

"Virt-manager is a desktop user interface for managing virtual machines. It presents a summary view of running domains, their live performance & resource utilization statistics. The detailed view graphs performance & utilization over time. Wizards enable the creation of new domains, and configuration & adjustment of a domain's resource allocation & virtual hardware. An embedded VNC client viewer presents a full graphical console to the guest domain"

You need to download virt-manager on the machine from which you wish to access your virtual machines. I am using a machine running Ubuntu 10.04 which I will call the client machine in the description below.

My Virtual Machines (VMs) were created on top of Xen 3.2 hypervisor, Earlier I had some issues getting the network up and running on my VMs, the resolution of which I have described in an earlier post. My hypervisor machine which I will call my host machine is running kernel 2.6.24-24-xen.

So here is the procedure that I followed to get virt-manager to work:

1. I used the Synaptic Package Manager (System->Administration->Synaptic Package Manager to download virt-manager and all the dependencies on my client machine. Alternatively, one could also do sudo apt-get install virt-manager


2. On my host machine, I downloaded and installed libvirt-bin and ssh-askpass

   sudo apt-get install libvirt-bin

   sudo apt-get install ssh-askpass



3. Now to access the virt-manager console from my client machine I used Application->System Tools->Virtual Machine Manager


4. On my host machine, I started the libvirtd daemon:

   sudo libvirtd start



5. At this point I tried to connect to my host machine using File->Add Connection...; I chose my specific hypervisor (Xen) and Connection as Remote Tunnel over SSH (I am not sure that this is the one that I was supposed to use, but it did work, eventually!)
   
   At this point, I got the following error on a pop-up on my client machine and on the console of my host machine:

   libvir: Xen Daemon error :internal error failed to connect to xend

   After some effort, the following fix worked:

   
   
   1. Open the xend configuration file

      sudo vim /etc/xen/xend-config.sxp

   
   
   2. In my previous post I had talked about adding a temporary bridge between physical network device and the virtual TAP device. I had to let the xend daemon become aware of this. So under the line:

      (network-script network-bridge)

      I added:

      (network-script 'network-bridge netdev=tmpbridge')

      (To recall what my network device is called, I did a ifconfig. It was the one whose description contains the domain-0's IP.
   
   
   3. I was not done with this file yet. I needed to add the following line somewhere in the file:

      (xend-unix-server yes)

   
   
   4. I saved and closed the file. Restarted the host machine's network (sudo /etc/init.d/networking restart), restarted the xend daemon (sudo xend restart), and finally restarted the libvirtd daemon( sudo libvirtd start)
      

   
   Now when I tried to add the connection using the setting mentioned above, it went through, asked me for a password and I would see a table giving the details of the CPU utilization and some other statistics of my VMs. Following is a screen shot of what I can see so far:
   
   
   

No network on Xen user domain

Today I installed Xen 3.2 for my work and created a guest VM using the this link as a guide. However I found that the network on my VM didn't work. The problem as Pierre explained was that the link between my physical network device and the virtual TAP device was not set up.

This was in spite of the fact that I re-started the xend daemon on my machine and used the static IP address method that was recommended in the blog mentioned above.So it seems that the xm create and xend scripts are not doing what they are supposed to do!

David Wolinsky came up with the following fix:
On the console of your control domain, do the following:

$ brctl addif tmpbridge eth0
$ ifup tmpbridge
$ ifconfig eth0 0.0.0.0 promisc
$ brctl show
$ dhclient tmpbridge

Now when you do an ifconfig on you domain-0, the tmpbridge interface should show up with the IP that was originally assigned to eth0.

And since eth0 is set to "promiscuous" mode, it will accept all network packages coming to it.

Now using the route command find the default gateway used by your domain-0. The following terminal snapshot is provided to clarify which IP I am talking about:


user@Domain0:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.5.144.0 * 255.255.240.0 U 0 0 0 tmpbridge
default 10.5.144.1 0.0.0.0 UG 0 0 0 tmpbridge



In the last line, the default gateway is highlighted in red. Make a note of this IP.
Now open the console of your user domain and check the route:


root@UserDomain:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.5.144.0 * 255.255.240.0 U 0 0 0 eth0


As you can see, in my case the default gateway was not set. To do so use the route add default gw command and the IP we obtained from the default gateway of domain-0.


root@UserDomain:~# route add default gw 10.5.144.1


Verify using route, and then try pinning something:


root@UserDomain:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.5.144.0 * 255.255.240.0 U 0 0 0 eth0
default 10.5.144.1 0.0.0.0 UG 0 0 0 eth0
root@UserDomain:~# ping google.com
PING google.com (72.14.253.104) 56(84) bytes of data.
64 bytes from mia04s03-in-f104.1e100.net (72.14.253.104): icmp_seq=1 ttl=56 time=15.5 ms
64 bytes from mia04s03-in-f104.1e100.net (72.14.253.104): icmp_seq=2 ttl=56 time=14.0 ms
64 bytes from mia04s03-in-f104.1e100.net (72.14.253.104): icmp_seq=3 ttl=56 time=13.9 ms



Dadaaa! Many thanks to Pierre and David!
As a side note, if you are adding more domains, you do not need to repeat all the commands on domain-0, as its interface is already in the "promiscuous" mode. Only run the dhclient again. You will however need to set up the default gateway in every new domain that you create.