Run libguestfs-test-tool¶

 libguestfs-test-tool

This command does a very simple, non-destructive test that basic libguestfs is functioning. You don't need to run it as root.

If it doesn't print "===== TEST FINISHED OK =====", report it as a bug. It is very important that you include the complete, unedited output of "libguestfs-test-tool" in your bug report. See the "BUGS" section at the end of this page.

Check KVM acceleration is being used.¶

 time guestfish -a /dev/null run

After a few runs, the time should settle down to a few seconds (under 5 seconds on fast 64 bit hardware).

How to check for hardware virt:

http://virt-tools.org/learning/check-hardware-virt/

If the command above does not work at all, use libguestfs-test-tool(1).

Check which version of libguestfs, qemu, libvirt, etc is being used.¶

• Which version of libguestfs is being used? Near the beginning of the output you'll see a line like:

   library version: 1.22.0fedora=19,release=1.fc19,libvirt
      

• Is libvirt being used? You can tell the difference by looking for the backend:

   guestfs_get_backend: direct
      

  або:

   guestfs_get_backend: libvirt
      

• Which version of qemu is being used? It may be printed out:

   libguestfs: qemu version 1.5
      

• Which kernel is being used? supermin(1) will try to pick the latest kernel installed on your machine. You can see the version in the appliance output, eg:

   [    0.000000] Linux version 3.9.2-200.fc18.x86_64 [...]
      

Try to open a local guest image with guestfish.¶

 guestfish --ro -a /path/to/disk.img -i

If the command is successful, it should print out the guest operating system name and put you at the guestfish "><fs>" prompt. You can use guestfish commands like "ll /" to look inside the disk image. To exit, type "exit".

If you get an error, try enabling debugging (add "-v" to the command line). Also make sure that libguestfs-test-tool(1) succeeds.

Try to open a remote guest image with guestfish.¶

 export LIBGUESTFS_BACKEND=direct

If you have a disk image available over HTTP/FTP, try to open it.

 guestfish --ro -i --format=raw -a http://www.example.com/disk.img

For SSH you will need to make sure that ssh-agent is set up so you don't need a password to log in to the remote machine. Then a command similar to this should work:

 guestfish --ro -i --format=raw \
   -a ssh://remote.example.com/path/to/disk.img

If you get an error, try enabling debugging (add "-v" to the command line). Also make sure that libguestfs-test-tool(1) succeeds.

Run virt-alignment-scan on all your guests.¶

 virt-alignment-scan -a /шлях/до/образу

або:

 virt-alignment-scan -d Guest

Does the alignment report match how the guest partitions are aligned?

Run virt-cat on some files in guests.¶

 virt-cat LinuxGuest /etc/passwd

A recent feature is support for Windows paths, for example:

 virt-cat WindowsGuest 'c:\windows\win.ini'

An even better test is if you have a Windows guest with multiple drives. Do "D:", "E:" etc paths work correctly?

* Copy some files into a shut off guest.¶

 virt-copy-in -d Guest /etc /tmp

This should copy local directory /etc to /tmp/etc in the guest (recursively). If you boot the guest, can you see all of the copied files and directories?

Shut the guest down and try copying multiple files and directories:

 virt-copy-in -d Guest /home /etc/issue /tmp

Copy some files out of a guest.¶

 virt-copy-out -d Guest /home .

Note the final space and period in the command is not a typo.

This should copy /home from the guest into the current directory.

Виконайте virt-df.¶

 virt-df

You can try comparing this to the results from df(1) inside the guest, but there are some provisos:

• The guest must be idle.
• The guest disks must be synched using sync(1).
• Any action such as booting the guest will write log files causing the numbers to change.

We don't guarantee that the numbers will be identical even under these circumstances. They should be similar. It would indicate a bug if you saw greatly differing numbers.

Try importing virt-df CSV output into a spreadsheet or database.¶

 virt-df --csv > /tmp/report.csv

Now try to load this into your favorite spreadsheet or database. Are the results reproduced faithfully in the spreadsheet/database?

http://www.postgresql.org/docs/8.1/static/sql-copy.html http://dev.mysql.com/doc/refman/5.1/en/load-data.html

* Edit a file in a shut off guest.¶

 virt-edit LinuxGuest /etc/sysconfig/network

On other Linux guests try editing other files such as:

 virt-edit LinuxGuest /etc/motd

Are the changes seen inside the guest when it is booted?

Display the filesystems / partitions / LVs in a guest.¶

 virt-filesystems -a /шлях/до/образу --all --long -h

або:

 virt-filesystems -d Guest --all --long -h

Do the results match what is seen in the guest?

Запустіть virt-inspector для всіх ваших гостьових систем.¶

 virt-inspector -a /шлях/до/образу | less

або:

 virt-inspector -d Guest | less

Do the results match what is actually in the guest?

If you have an unusual guest (a rare Linux distro, a very new version of Windows), does virt-inspector recognize it? If not, then it's probably a bug.

Try the auditing features of virt-ls on all your guests.¶

 virt-ls -lR -d Guest / | grep '^- [42]'

Показати список всіх каталогів з відкритим для всіх доступом на запис у віртуальній машині Linux:

 virt-ls -lR -d Guest / | grep '^d ...7'

Показати список всіх сокетів доменів Unix у віртуальній машині Linux:

 virt-ls -lR -d Guest / | grep '^s'

Показати список всіх звичайних файлів, назви яких завершуються на «.png»:

 virt-ls -lR -d Guest / | grep -i '^-.*\.png$'

Щоб переглянути список файлів у домашніх каталогах, розмір яких перевищує 10 МБ:

 virt-ls -lR -d Guest /home | awk '$3 > 10*1024*1024'

Знайти всі об’єкти, які було змінено протягом попередніх 7 днів:

 virt-ls -lR -d Guest --time-days / | awk '$6 <= 7'

Знайти звичайні файли, зміни до яких було внесено протягом попередніх 24 годин:

 virt-ls -lR -d Guest --time-days / | grep '^-' | awk '$6 < 1'

Do the results match what is in the guest?

Create a disk image from a tarball.¶

 virt-make-fs --partition=mbr --type=vfat /десь/якийсь.tar.gz образ_результат.img

Add 'output.img' as a raw disk to an existing guest. Check the guest can see the files. This test is particularly useful if you try it with a Windows guest.

Try other partitioning schemes, eg. --partition=gpt.

Try other filesystem formats, eg. --type=ntfs, --type=ext2.

* Run virt-rescue on a shut off disk image or guest.¶

 virt-rescue -a /шлях/до/образу.img

або:

 virt-rescue -d Guest

Can you use ordinary shell commands to examine the guest?

* Resize your guests.¶

 truncate -s 30G newdisk.img
 virt-filesystems -a /path/to/olddisk.img --all --long -h
 virt-resize /path/to/olddisk.img newdisk.img --expand /dev/sda1
 qemu-kvm -m 1024 -hda newdisk.img

Does the guest still boot? Try expanding other partitions.

* Sparsify a guest disk.¶

 virt-sparsify /path/to/olddisk.img newdisk.img

Is newdisk.img still bootable after sparsifying? Is the resulting disk image smaller (use "du" to check)?

Build and boot a guest¶

 virt-builder -l

build it:

 virt-builder -o disk.img [os-version from list above]

and boot it:

 qemu-kvm -cpu host -m 2048 -drive file=disk.img,format=raw

Does it boot?

* "Sysprep" a shut off Linux guest.¶

 virt-sysprep --hostname newhost.example.com -a /path/to/disk.img

Was the sysprep successful? After booting, what changes were made and were they successful?

Dump the Windows Registry from your Windows guests.¶

 virt-win-reg --unsafe-printable-strings WindowsGuest 'HKLM\Software' |
   less

 virt-win-reg --unsafe-printable-strings WindowsGuest 'HKLM\System' |
   less

Does the output match running "regedit" inside the guest?

A recent feature is the ability to dump user registries, so try this, replacing username with the name of a local user in the guest:

 virt-win-reg --unsafe-printable-strings WindowsGuest 'HKEY_USERS\користувач' |
   less