[PATCH 0/3] Inspection code in C
by Richard W.M. Jones
These three patches (two were previously posted) can do simple
operating system inspection in C.
Example of use:
><fs> add-ro rhel55.img
><fs> run
><fs> inspect-os
/dev/VolGroup00/LogVol00
><fs> inspect-get-type /dev/VolGroup00/LogVol00
linux
><fs> inspect-get-distro /dev/VolGroup00/LogVol00
rhel
><fs> inspect-get-arch /dev/VolGroup00/LogVol00
x86_64
><fs> inspect-get-major-version /dev/VolGroup00/LogVol00
5
><fs> inspect-get-minor-version /dev/VolGroup00/LogVol00
5
><fs> inspect-get-product-name /dev/VolGroup00/LogVol00
Red Hat Enterprise Linux Server release 5.5 (Tikanga)
><fs> inspect-get-filesystems /dev/VolGroup00/LogVol00
/dev/VolGroup00/LogVol00
/dev/vda1
/dev/VolGroup00/LogVol01
><fs> inspect-get-mountpoints /dev/VolGroup00/LogVol00
/dev/VolGroup00/LogVol00: /
/dev/vda1: /boot
I've tested this with all of my available guests. The only ones it
*doesn't* work on were a Fedora guest with an encrypted disk, and some
FreeBSD/PCBSD guests. For the encrypted guest, you have to open the
device first. We could probably get the *BSD guests working with some
effort.
Anyway I'm quite happy with this and I intend to push it if no one
objects.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
14 years, 4 months
[PATCH] Enable coredumps to be captured from the appliance (RHBZ#619334).
by Richard W.M. Jones
https://bugzilla.redhat.com/show_bug.cgi?id=619334
This is a slightly unsatisfactory patch which allows coredumps to be
captured when they occur inside the appliance. You can capture
coredumps by doing:
export LIBGUESTFS_COREDUMP=/sysroot/core.%t.%p.%e
or equivalently:
g.set_coredump ("/sysroot/core.%t.%p.%e")
or variations thereof, see the manual page.
When a coredump occurs, a core file will be dropped into the root
directory of the currently mounted guest disk. If it is guestfsd
which crashes, then the appliance will exit, but I have checked that
the coredump is written and synched first. You can then copy this out
of the guest disk using guestfish and debug using gdb:
$ guestfish --ro -a guest_disk -m /dev/vg/lv_root
><fs> ll /
><fs> download /core.xxx.yyy.zzz core
$ gdb daemon/guestfsd core
http://fedoraproject.org/wiki/StackTraces#Obtaining_a_stack_trace_from_a_...
Clearly you need to have a writable guest disk mounted for this to
work, and you have to not care too much about having large core files
written to it.
Ideally we would have liked to use a special capture disk, but it
turns out that the kernel contains code which disallows using a /dev
device (or any non-regular file) for coredumps:
http://lxr.linux.no/linux+v2.6.34.1/fs/exec.c#L1930
We could do it using a coredump-to-pipe, but I think it would be
better to just remove this limitation in the kernel.
Another shortcoming is that a coredump isn't a stack trace, and to get
a stack trace you really need a copy of the daemon around with
debugging enabled. It is possible we could change the RPM packaging
to ship this.
Luckily the suspected bug in Augeas which we are chasing (RHBZ#613967)
happens in aug_init or aug_save when the conditions above are
satisfied and we should be able to get a useful coredump. However
since I am unable to reproduce this bug at all, I cannot help with
this, so it's over to Marek and Matt.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
14 years, 4 months
Create new Sys::VirtV2V::Util
by Matthew Booth
These 2 patches are mostly code motion. They were prompted by an apparent augeas
error in BZ 613967 which didn't display useful error message. The error seems to
happen in Converter::Linux. GuestOS::RedHat had a handy function which displayed
verbose augeas error messages. This function moves into the new module where it
can be used by both modules.
The second patch is an consequential tidy up. UserMessage moves into the new
module.
* [PATCH 1/2] Move augeas error reporting into new Sys::VirtV2V::Util
* [PATCH 2/2] Move user_message into Sys::VirtV2V::Util
14 years, 4 months
RHEL 6 guest support
by Matthew Booth
The following patches add RHEL 6 guest support to virt-v2v. This was actually
quite a lot easier than I expected.
* [PATCH 1/4] Update virt-v2v.conf for RHEL 6 virtio support
* [PATCH 2/4] Check kudzu exists before attempting to disable it
* [PATCH 3/4] Use dracut rather than mkinitrd if it's available
* [PATCH 4/4] Properly convert RHEL 6 guest console
14 years, 4 months
Inspection code in C
by Richard W.M. Jones
Currently virt-inspector is a Perl script[1], which uses a Perl
library called Sys::Guestfs::Lib[2]. This library contains (amongst
other things) heuristics for determining what operating system is in a
disk image. The library is the basis for both virt-inspector and
virt-v2v.
[1] http://git.annexia.org/?p=libguestfs.git;a=blob;f=inspector/virt-inspecto...
[2] http://git.annexia.org/?p=libguestfs.git;a=blob;f=perl/lib/Sys/Guestfs/Li...
Writing these in Perl was useful at the time because they involved a
lot of string matching, and rules which we thought would change
frequently. However these have proved to be simpler and more stable
than we originally thought.
If we rewrite these rules in C and make them available as part of the
core libguestfs API, then we gain some benefits:
(a) The generator will create bindings for us in all languages.
(b) We don't need to run an external virt-inspector binary to
implement the "guestfish -i" option, which means that option will
work much faster and with fewer limitations.
(c) We can get rid of the inspector-generator code which only works
for OCaml, is a big hack, and is not used by anyone.
(d) People can write tools like virt-edit, virt-cat, virt-inspector,
virt-v2v in languages other than Perl.
The downside is that this will become a core API which we cannot break
(because of the C ABI guarantee).
The main issues (hardest first) are:
(i) How to map the current tree structure returned by Sys::Guestfs::-
Lib into the flat list-of-structures that the generator supports (or
modifying the generator to support trees, but that is much more
complex and I don't think necessary).
(ii) Decide on the final API.
(iii) Decide how much of the current API to move to C.
The current "inspect_in_detail" call lists applications, kernels,
drivers etc installed in the guest. Furthermore the current API
exposes a lot of information about individual filesystems, such as
their UUID, which is nowadays unnecessary since we added calls such as
guestfs_vfs_uuid to the main libguestfs API. I don't think it's
necessary to move all of this into C. We can move it later if we want
to, or leave it to the higher level tools.
But it's not necessary to gain the benefits (a) through (d) above.
As a result, the proposed API below is considerably simpler than
the current Perl API, which (I think) exposing all the important
information that anyone cares about and cannot be derived in any
other way.
(iv) Modify virt-v2v and virt-inspector to use the new API.
(v) Introduces a direct dependency on hivex.
Please read the proposed API below, and let me know what you think.
Rich.
----------------------------------------------------------------------
/* Inspect and return list of operating systems found.
* Returned list empty => no operating systems found.
* 1 element => single operating system found.
* > 1 element => multi-boot image.
*/
char ** /* list of root devices */
guestfs_inspect_os (guestfs_h *g);
/* Pass in a root device of one of the operating systems. These
* functions return ancillary information such as the name of the
* OS, version numbers, etc. If it could not be determined, these
* return an error.
*/
char *
guestfs_inspect_get_name (guestfs_h *g, const char *root);
char *
guestfs_inspect_get_arch (guestfs_h *g, const char *root);
char *
guestfs_inspect_get_distro (guestfs_h *g, const char *root);
char *
guestfs_inspect_get_product_name (guestfs_h *g, const char *root);
int
guestfs_inspect_get_major_version (guestfs_h *g, const char *root);
int
guestfs_inspect_get_minor_version (guestfs_h *g, const char *root);
char *
guestfs_inspect_get_package_format (guestfs_h *g, const char *root);
char *
guestfs_inspect_get_package_management (guestfs_h *g, const char *root);
char ** /* hash of mount point -> device */
guestfs_inspect_get_mountpoints (guestfs_h *g, const char *root);
char ** /* list of filesystems */
guestfs_inspect_get_filesystems (guestfs_h *g, const char *root);
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
14 years, 5 months
Fwd: [PATCH hivex] non-ASCII characters in node names
by Richard W.M. Jones
Hilko, forwarding this to the mailing list. Please post patches
over there.
Rich.
----- Forwarded message -----
Date: Wed, 21 Jul 2010 17:09:53 +0200
From: Hilko Bengen
Subject: patch: non-ASCII characters in node names
Hi Richard,
I was a little bit surprised when a colleague claimed that key and value
names in the registry could contain non-ASCII characters.
I created keys and values with the following names:
* "asdf"
* "äöü" (common in German, can be represented in Windows-1252, Latin1,
Latin9)
* the Euro sign (can be represented in Windows-1252, Latin9)
* the international currency symbol (can be represented in Windows-1252,
Latin1)
>From looking at the nodes/values, I have come to the conclusion that
Windows first looks if all characters in a string can be represented in
the Latin1 encoding. If that fails, UTF-16 is used. A bit in the "flags"
field is used to indicate the character encoding.
I have implemented and briefly tested read support for those names in
the patch below. If that patch is acceptable, I'll do write support
tomorrow.
-Hilko
----- End forwarded message -----
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
14 years, 5 months
