Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

Getting ready for the new Ubuntu LTS release (smile)

It looks good, and it feels fast. Rebooting a VM takes 9 seconds, which is faster than ever. No need to schedule maintenance windows any more (not that I did anyway (wink)).

Network interface configuration and DNS resolution

Things have changed. Both interface configuration and name resolution configuration are now done in /etc/network/interfaces. There is a new flag for autoconfiguration, so no need to echo things to /proc anymore. For our dual stack staticly configured servers the configuration looks like this:

 

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
        address 192.87.30.54
        netmask 255.255.255.192
        gateway 192.87.30.1
# This is a statically configured IPv6 interface
iface eth0 inet6 static
        autoconf 0
        privext 0
        address 2001:610:148:dead::54
        gateway 2001:610:148:dead::1
        netmask 64
        accept_ra 0
        dns-search terena.org
        dns-domain terena.org
        dns-nameservers 2001:610:1:800a:192:87:106:106 2001:610:188:140:145:100:188:188

Note that despite the comment on the second line (see interfaces(5)), not everything is explained there. You have to look at resolvconf(8) as well.

There is a bug that effectively overrides the privext value with what's in /etc/sysctl.d/10-ipv6-privacy.conf. You have to work around it by commenting out the two lines there.

 

VMware tools

Our setup consists of VMware ESXi 4.1 boxes, and I configured the Precise VMs with a vmxnet3 NIC, and a paravirtualised SCSI hard disk, and the linux-image-virtual kernel.

When it comes to the VMware tools, there are a few options:

1 - Do nothing

This is the simplest approach, and usually my favourite. A freshly installed VM will load a number of VMware modules that apparently are part of the 3.2 kernel these days:

[    2.135796] VMware PVSCSI driver - version 1.0.1.0-k
[    2.136064] vmw_pvscsi 0000:03:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[    2.136279] vmw_pvscsi: using 64bit dma
[    2.136688] VMware vmxnet3 virtual NIC driver - version 1.1.29.0-k-NAPI
[    2.137030] vmxnet3 0000:0b:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[    2.137217] vmxnet3 0000:0b:00.0: setting latency timer to 64
[    2.201568] vmxnet3 0000:0b:00.0: (unregistered net_device): features: sg csum vlan jf tso tsoIPv6 lro highDMA
[    2.202810] vmxnet3 0000:0b:00.0: irq 72 for MSI/MSI-X
[    2.202837] vmxnet3 0000:0b:00.0: irq 73 for MSI/MSI-X
[    2.202863] vmxnet3 0000:0b:00.0: irq 74 for MSI/MSI-X
[    2.202890] vmxnet3 0000:0b:00.0: irq 75 for MSI/MSI-X
[    2.202916] vmxnet3 0000:0b:00.0: irq 76 for MSI/MSI-X
[    2.203752] vmw_pvscsi 0000:03:00.0: setting latency timer to 64
[    2.205264] vmw_pvscsi 0000:03:00.0: irq 77 for MSI/MSI-X
[    2.205322] vmw_pvscsi: using MSI-X
[    2.205497] scsi2 : VMware PVSCSI storage adapter rev 2, req/cmp/msg rings: 8/8/1 pages, cmd_per_lun=64
[    2.205775] vmw_pvscsi 0000:03:00.0: VMware PVSCSI rev 2 host #2
[    2.206296] scsi 2:0:0:0: Direct-Access     VMware   Virtual disk     1.0  PQ: 0 ANSI: 2

Also, it will load the vmw_balloon module.

I'd say all of this is an improvement over the "do nothing" approach in Lucid, because back then no specific VMware modules would be loaded at all. But now, VCenter still displays "Not installed" as the VMware Tools status...

2 - Distro provided OpenVM-tools

This is slightly more work than the "do nothing" scenario, but it's very easy because everything sits in the Ubuntu repository. To install the OpenVM-tools on a server be sure to leave out the recommended packages, so that you don't end up with tons of unnecessary X-server packages:

apt-get install --no-install-recommends linux-headers-virtual open-vm-dkms open-vm-tools

The open-vm-dkms package takes care of automatically rebuilding modules whenever there is a kernel upgrade. You can see this in action when installing it:

Setting up open-vm-dkms (2011.12.20-562307-0ubuntu1) ...
Loading new open-vm-tools-2011.12.20 DKMS files...
First Installation: checking all kernels...
Building only for 3.2.0-23-virtual
Building for architecture x86_64
Building initial module for 3.2.0-23-virtual
Done.

After this there are quite some vm modules loaded:

root@precise:~# lsmod | grep vm
vmxnet                 26931  0
vmblock                18757  0
vmsync                 13024  0
vmhgfs                 63406  0
vmci                   97231  1 vmhgfs
vmw_balloon            12809  0
vmw_pvscsi             22881  1
vmxnet3                45922  0

VCenter now says the VMware Tools status is "Unmanaged" - slightly better than nothing.

 

3 - VMware provided tools

This is the most work, but it's not too hard.

It basically comes down to:

  1. in vSphere client: right-click Guest -> Install/Upgrade VMware tools
  2. In the guest: mount /dev/cdrom /media/cdrom, then extract the tar.gz
  3. Install the tools using vmware-install.pl --default
Unfortunately the tools that come with ESXi 4.1 are rather old (VMwareTools-8.3.2-257589.tar.gz) and hence don't compile very well on Precise 12.04.
I tried the tools that come with VMware Workstation 8.0.2, which are much newer (VMwareTools-8.8.2-590212.tar.gz) and which worked well on my Workstation.
The VMware Tools will have status OK after this is installed.

 

I will run some test to see which scenarios allow VCB to make backups.

 

/sbin/halt doesn't power off any more

This bug functionality change appears to have been introduced in 11.10, but because I only use LTS I didn't find out until now.

Easy workaround: issue "halt -p".

  • No labels