lost and found ( for me ? ): May 2014

KVM : build Ubuntu 14.04 VM via CLI(virt-install)

You can easily build VMs with virt-install ( no GUI )

The procedures are:

Download ISO

Mount ISO locally

Build VM with virt-install

Here are logs when building Ubuntu 14.04 VMs within Ubuntu13.10 KVM host.

KVM host

# tail -1 /etc/lsb-release ; uname -ri

DISTRIB_DESCRIPTION="Ubuntu 13.10"

3.11.0-20-generic x86_64

# qemu-system-x86_64 -version

download ISO

ubuntu-14.04-server-amd64.iso

mount ISO

# mount -t iso9660 -o loop ubuntu-14.04-server-amd64.iso /var/iso-mnt

build VM. ( memory 512M, vHDD 10GB )

# virt-install --connect qemu:///system -n ubuntu1404-vm1 -s 10 -r 512 -f /var/lib/KVM_images/ubuntu1404-vm1.img --vcpus=1 --os-type linux --os-variant ubuntutrusty --nographics --location /var/iso-mnt --extra-args='console=tty0 console=ttyS0,115200n8' --keymap ja

virt-sysprep : error while loading shared libraries: libcap.so.2

When I use virt-sysprep, I saw the following errors.

guestfsd: error while loading shared libraries: libcap.so.2: cannot open shared object file: No such file or directory

In my case, after upgrading an appliance of guestfs with “update-guestfs-appliance” command, I could solve this error.

Here are trial and error logs I did.

KVM host: Ubuntu 13.10

virtual machine: CentOS 6.5

# guestfish --version

guestfish 1.22.4

# virt-sysprep --version

virt-sysprep 1.22.4

# qemu-system-x86_64 --version

error

# virt-sysprep --enable ssh-hostkeys,udev-persistent-net -a /var/lib/KVM_images/foobar.qcow2

Examining the guest ...

Fatal error: exception Guestfs.Error("guestfs_launch failed.

This usually means the libguestfs appliance failed to start or crashed.

See http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs

or run 'libguestfs-test-tool' and post the *complete* output into a

bug report

run as debug mode.

# virt-sysprep --enable ssh-hostkeys,udev-persistent-net -a /var/lib/KVM_images/foobar.qcow2

guestfsd: error while loading shared libraries: libcap.so.2: cannot open shared object file: No such file or directory

[ 1.395248] Unregister pv shared memory for cpu 0

[ 1.395959] sd 2:0:1:0: [sdb] Synchronizing SCSI cache

[ 1.397359] sd 2:0:0:0: [sda] Synchronizing SCSI cache

[ 1.398840] reboot: Restarting system

[ 1.399376] reboot: machine restart

libguestfs: child_cleanup: 0x2288f30: child process died

libguestfs: sending SIGTERM to process 12114

Fatal error: exception Guestfs.Error("guestfs_launch failed, see earlier error messages")

libguestfs: closing guestfs handle 0x2288f30 (state 0)

libguestfs: command: run: rm

libguestfs: command: run: \ -rf /tmp/libguestfsiwwYZ1

run libguestfs-test-tool.

same errors.

# libguestfs-test-tool

uptime: 1.29 0.74

guestfsd: error while loading shared libraries: libcap.so.2: cannot open shared object file: No such file or directory

[ 1.304720] Unregister pv shared memory for cpu 0

[ 1.305483] sd 2:0:1:0: [sdb] Synchronizing SCSI cache

[ 1.306562] sd 2:0:0:0: [sda] Synchronizing SCSI cache

[ 1.339817] reboot: Restarting system

[ 1.340285] reboot: machine restart

libguestfs: error: appliance closed the connection unexpectedly, see earlier error messages

libguestfs: child_cleanup: 0x24399a0: child process died

libguestfs: sending SIGTERM to process 14987

libguestfs: error: guestfs_launch failed, see earlier error messages

libguestfs-test-tool: failed to launch appliance

libguestfs: closing guestfs handle 0x24399a0 (state 0)

libguestfs: command: run: rm

libguestfs: command: run: \ -rf /tmp/libguestfssEis6M

update appliance.

# update-guestfs-appliance

run libuestfs-test-tool again.

Okay.

# libguestfs-test-tool

umount /sysroot

fsync /dev/sda

guestfsd: main_loop: proc 282 (internal_autosync) took 0.03 seconds

libguestfs: sending SIGTERM to process 17227

libguestfs: closing guestfs handle 0x25579a0 (state 0)

libguestfs: command: run: rm

libguestfs: command: run: \ -rf /tmp/libguestfsuIeeBb

===== TEST FINISHED OK =====

run virt-sysprep. okay.

# virt-sysprep --enable ssh-hostkeys,udev-persistent-net,random-

seed -a /var/lib/KVM_images/foobar.qcow2

Examining the guest ...

Performing "random-seed" ...

Performing "ssh-hostkeys" ...

Performing "udev-persistent-net" ...

BIND 9.10 dig tool support EDNS client subnet

Seen from release notes of BIND 9.10, dig tool included in BIND 9.10 supports EDNS client subnet.

Before BIND 9.10, we need to apply a patch to use EDNS client subnet with dig.

README

- "dig +subnet" sends an EDNS CLIENT-SUBNET option when

querying.

build BIND 9.10 on Ubuntu 14.04.

# tail -1 /etc/lsb-release

DISTRIB_DESCRIPTION="Ubuntu 14.04 LTS"

# apt-get install build-essential libssl-dev

# tar xzvf bind-9.10.0-P1.tar.gz

# cd bind-9.10.0-P1

# ./configure

# make

# make install

# /usr/local/bin/dig -v

DiG 9.10.0-P1

# /usr/local/bin/dig -h | grep subnet

+subnet=addr (Set edns-client-subnet option)

Google public DNS support EDNS client subnet, send DNS queries to Google Public DNS.

You can send EDNS client subnet queries with +subnet option.

# /usr/local/bin/dig @8.8.8.8 +subnet=1.0.16.0 www.google.com +short

173.194.38.18

173.194.38.16

173.194.38.19

173.194.38.20

173.194.38.17

# /usr/local/bin/dig @8.8.8.8 +subnet=3.0.0.0 www.google.com +short

74.125.226.210

74.125.226.211

74.125.226.208

74.125.226.212

74.125.226.209

/dev/full : always full device

small tips.

You can check how your program handles disk-full errors by using /dev/full device.

from man manual.

root@ubuntu:~# man full

DESCRIPTION

File /dev/full has major device number 1 and minor device number 7.

Writes to the /dev/full device will fail with an ENOSPC error. This

can be used to test how a program handles disk-full errors.

Reads from the /dev/full device will return \0 characters.

Seeks on /dev/full will always succeed.

sample usage.

root@ubuntu:~# tail -1 /etc/lsb-release ;uname -ri

DISTRIB_DESCRIPTION="Ubuntu 14.04 LTS"

3.13.0-24-generic x86_64

root@ubuntu:~# echo hello > /dev/full

-su: echo: write error: No space left on device

root@ubuntu:~# echo $?

root@ubuntu:~#

root@ubuntu:~# echo hello > /dev/null

root@ubuntu:~# echo $?

I didn’t know that..