1
0
Fork 0
mirror of https://github.com/fog/fog.git synced 2022-11-09 13:51:43 -05:00
fog--fog/lib/fog/libvirt/models/compute
2012-01-25 16:16:39 +02:00
..
templates fixed missing disk-> volume conversion 2011-09-19 14:23:08 +02:00
interface.rb
interfaces.rb [Libvirt] renamed 'raw' connection to raw in the Fog Connection 2011-09-13 07:34:18 +02:00
network.rb
networks.rb
node.rb
nodes.rb * remove unnecessary debugging 2011-11-30 10:35:16 +01:00
pool.rb [Libvirt] renamed 'raw' connection to raw in the Fog Connection 2011-09-13 07:34:18 +02:00
pools.rb [Libvirt] renamed 'raw' connection to raw in the Fog Connection 2011-09-13 07:34:18 +02:00
README.md
server.rb fixes libvirt wrong state check 2012-01-25 14:32:47 +02:00
servers.rb libvirt: servers return nil, not an empty array... 2012-01-25 16:16:39 +02:00
uri.rb [Compute|Libvirt] Take into account a query string can be empty, different on some rubies it gives nil, on some empty string 2011-09-30 16:13:24 +02:00
util.rb minor cleanups 2012-01-25 14:32:47 +02:00
volume.rb [Libvirt] renamed 'raw' connection to raw in the Fog Connection 2011-09-13 07:34:18 +02:00
volumes.rb [Libvirt] renamed 'raw' connection to raw in the Fog Connection 2011-09-13 07:34:18 +02:00

This model implements the connection with a libvirt URI. A libvirt URI can either be local or remote.

To learn more on the specific libvirt URI syntax see:

Only ssh is supported as the transport for remote URI's. TLS is NOT supported, as we can't easily login to the server

Dependencies

  • the interaction with libvirt is done through the official libvirt gem called 'libvirt-ruby'.

  • be aware that there is another libvirt gem called 'libvirt', which is not compatible

  • If this gem is not installed the models for libvirt will not be available

  • libvirt needs to be setup so that it can be used

  • for a remote ssh connection this requires to be member of the libvirt group before you can use the libvirt commands

  • verify if you can execute virsh command to see if you have correct access

Libvirt on Macosx

  • There is a libvirt client for Macosx, available via homebrew
  • By default this will install things in /usr/local/somewhere
  • This means that also the default locations of the libvirt-socket are assumed to be in /usr/local
  • To check the connection you need to override your libvirt socket location in the URI
    • "qemu+ssh://patrick@myserver/system?socket=/var/run/libvirt/libvirt-sock"

Configuration

The URI can be configured in two ways:

  1. via the .fog file :default :libvirt_uri: "qemu+ssh://patrick@myserver/system?socket=/var/run/libvirt/libvirt-sock"

  2. you can also pass it during creation : f=Fog::Compute.new(:provider => "Libvirt", :libvirt_uri => "qemu+ssh://patrick@myserver/system")

IP-addresses of guests

Libvirt does not provide a way to query guests for Ip-addresses. The way we solve this problem is by installing arpwatch: this watches an interface for new mac-addresses and ip-addresses requested by DHCP We query that logfile for the mac-address and can retrieve the ip-address

vi /etc/rsyslog.d/30-arpwatch.conf #:msg, contains, "arpwatch:" -/var/log/arpwatch.log #& ~ if $programname =='arpwatch' then /var/log/arpwatch.log & ~

This log files needs to be readable for the users of libvirt

SSh-ing into the guests

Once we have retrieved the ip-address of the guest we can ssh into it. This works great if the URI is local. But when the URI is remote our machine can't ssh directly into the guest sometimes (due to NAT or firewall issues)

Luckily libvirt over ssh requires netcat to be installed on the libvirt server. We use this to proxy our ssh requests to the guest over the ssh connection to the libvirt server. Thanks to the requirement that you need ssh login to work to a libvirt server, we can login and tunnel the ssh to the guest.

Bridge configuration (slowness)

We had noticed that sometimes it takes about 30 seconds before the server gets a DHCP response from the server. In our case it was because the new machine Mac-address was not allowed immediately by the bridge. Adding the flag 'bridge_fd 0' solved that problem.

/etc/network/interfaces auto br0 iface br0 inet static address 10.247.4.13 netmask 255.255.255.0 network 10.247.4.0 broadcast 10.247.4.255 bridge_ports eth0.4 bridge_stp on bridge_maxwait 0 bridge_fd 0