1virt-inspector2(1) Virtualization Support virt-inspector2(1)
2
6 virt-inspector2 - Display operating system version and other
7 information about a virtual machine
8
10 virt-inspector2 [--options] -d domname
11 virt-inspector2 [--options] -a disk.img [-a disk.img ...]
13 Old-style:
15 virt-inspector2 domname
17 virt-inspector2 disk.img [disk.img ...]
19
21 virt-inspector2 examines a virtual machine or disk image and tries to
22 determine the version of the operating system and other information
23 about the virtual machine.
24 Virt-inspector2 produces XML output for feeding into other programs.
26 In the normal usage, use "virt-inspector2 -d domname" where "domname"
28 is the libvirt domain (see: "virsh list --all").
29 You can also run virt-inspector2 directly on disk images from a single
31 virtual machine. Use "virt-inspector2 -a disk.img". In rare cases a
32 domain has several block devices, in which case you should list several
33 -a options one after another, with the first corresponding to the
34 guest's "/dev/sda", the second to the guest's "/dev/sdb" and so on.
35 You can also run virt-inspector2 on install disks, live CDs, bootable
37 USB keys and similar.
38 Virt-inspector2 can only inspect and report upon one domain at a time.
40 To inspect several virtual machines, you have to run virt-inspector2
41 several times (for example, from a shell script for-loop).
42 Because virt-inspector2 needs direct access to guest images, it won't
44 normally work over remote libvirt connections.
45 All of the information available from virt-inspector2 is also available
47 through the core libguestfs inspection API (see "INSPECTION" in
48 guestfs(3)). The same information can also be fetched using guestfish
49 or via libguestfs bindings in many programming languages (see "GETTING
50 INSPECTION DATA FROM THE LIBGUESTFS API").
51
53 --help
54 Display brief help.
55 -a file
57 --add file
58 Add file which should be a disk image from a virtual machine. If
59 the virtual machine has multiple block devices, you must supply all
60 of them with separate -a options.
61 The format of the disk image is auto-detected. To override this
63 and force a particular format use the --format=.. option.
64 -c URI
66 --connect URI
67 If using libvirt, connect to the given URI. If omitted, then we
68 connect to the default libvirt hypervisor.
69 Libvirt is only used if you specify a "domname" on the command
71 line. If you specify guest block devices directly (-a), then
72 libvirt is not used at all.
73 -d guest
75 --domain guest
76 Add all the disks from the named libvirt guest. Domain UUIDs can
77 be used instead of names.
78 --echo-keys
80 When prompting for keys and passphrases, virt-inspector2 normally
81 turns echoing off so you cannot see what you are typing. If you
82 are not worried about Tempest attacks and there is no one else in
83 the room you can specify this flag to see what you are typing.
84 --format=raw|qcow2|..
86 --format
87 Specify the format of disk images given on the command line. If
88 this is omitted then the format is autodetected from the content of
89 the disk image.
90 If disk images are requested from libvirt, then this program asks
92 libvirt for this information. In this case, the value of the
93 format parameter is ignored.
94 If working with untrusted raw-format guest disk images, you should
96 ensure the format is always specified.
97 --keys-from-stdin
99 Read key or passphrase parameters from stdin. The default is to
100 try to read passphrases from the user by opening "/dev/tty".
101 -v
103 --verbose
104 Enable verbose messages for debugging.
105 -V
107 --version
108 Display version number and exit.
109 -x Enable tracing of libguestfs API calls.
111 --xpath query
113 Perform an XPath query on the XML on stdin, and print the result on
114 stdout. In this mode virt-inspector2 simply runs an XPath query;
115 all other inspection functions are disabled. See "XPATH QUERIES"
116 below for some examples.
117
119 Previous versions of virt-inspector2 allowed you to write either:
120 virt-inspector2 disk.img [disk.img ...]
122 or
124 virt-inspector2 guestname
126 whereas in this version you should use -a or -d respectively to avoid
128 the confusing case where a disk image might have the same name as a
129 guest.
130 For compatibility the old style is still supported.
132
134 The virt-inspector2 XML is described precisely in a RELAX NG schema
135 file "virt-inspector2.rng" which is supplied with libguestfs. This
136 section is just an overview.
137 The top-level element is <operatingsystems>, and it contains one or
139 more <operatingsystem> elements. You would only see more than one
140 <operatingsystem> element if the virtual machine is multi-boot, which
141 is vanishingly rare in real world VMs.
142 <operatingsystem>
144 In the <operatingsystem> tag are various optional fields that describe
145 the operating system, its architecture, the descriptive "product name"
146 string, the type of OS and so on, as in this example:
147 <operatingsystems>
149 <operatingsystem>
150 <root>/dev/sda2</root>
151 <name>windows</name>
152 <arch>i386</arch>
153 <distro>windows</distro>
154 <product_name>Windows 7 Enterprise</product_name>
155 <product_variant>Client</product_variant>
156 <major_version>6</major_version>
157 <minor_version>1</minor_version>
158 <windows_systemroot>/Windows</windows_systemroot>
159 <format>installed</format>
160 In brief, <name> is the class of operating system (something like
162 "linux" or "windows"), <distro> is the distribution (eg. "fedora" but
163 many other distros are recognized) and <arch> is the guest
164 architecture. The other fields are fairly self-explanatory, but
165 because these fields are taken directly from the libguestfs inspection
166 API you can find precise information from "INSPECTION" in guestfs(3).
167 The <root> element is the root filesystem device, but from the point of
169 view of libguestfs (block devices may have completely different names
170 inside the VM itself).
171 <mountpoints>
173 Un*x-like guests typically have multiple filesystems which are mounted
174 at various mountpoints, and these are described in the <mountpoints>
175 element which looks like this:
176 <operatingsystems>
178 <operatingsystem>
179 ...
180 <mountpoints>
181 <mountpoint dev="/dev/vg_f13x64/lv_root">/</mountpoint>
182 <mountpoint dev="/dev/sda1">/boot</mountpoint>
183 </mountpoints>
184 As with <root>, devices are from the point of view of libguestfs, and
186 may have completely different names inside the guest. Only mountable
187 filesystems appear in this list, not things like swap devices.
188 <filesystems>
190 <filesystems> is like <mountpoints> but covers all filesystems
191 belonging to the guest, including swap and empty partitions. (In the
192 rare case of a multi-boot guest, it covers filesystems belonging to
193 this OS or shared with this OS and other OSes).
194 You might see something like this:
196 <operatingsystems>
198 <operatingsystem>
199 ...
200 <filesystems>
201 <filesystem dev="/dev/vg_f13x64/lv_root">
202 <type>ext4</type>
203 <label>Fedora-13-x86_64</label>
204 <uuid>e6a4db1e-15c2-477b-ac2a-699181c396aa</uuid>
205 </filesystem>
206 The optional elements within <filesystem> are the filesystem type, the
208 label, and the UUID.
209 <applications>
211 The related elements <package_format>, <package_management> and
212 <applications> describe applications installed in the virtual machine.
213 <package_format>, if present, describes the packaging system used.
215 Typical values would be "rpm" and "deb".
216 <package_management>, if present, describes the package manager.
218 Typical values include "yum", "up2date" and "apt"
219 <applications> lists the packages or applications installed.
221 <operatingsystems>
223 <operatingsystem>
224 ...
225 <applications>
226 <application>
227 <name>coreutils</name>
228 <version>8.5</version>
229 <release>1</release>
230 </application>
231 The version and release fields may not be available for some types
233 guests. Other fields are possible, see
234 "guestfs_inspect_list_applications" in guestfs(3).
235 <drive_mappings>
237 For operating systems like Windows which use drive letters, virt-
238 inspector2 is able to find out how drive letters map to filesystems.
239 <operatingsystems>
241 <operatingsystem>
242 ...
243 <drive_mappings>
244 <drive_mapping name="C">/dev/sda2</drive_mapping>
245 <drive_mapping name="E">/dev/sdb1</drive_mapping>
246 </drive_mappings>
247 In the example above, drive C maps to the filesystem on the second
249 partition on the first disk, and drive E maps to the filesystem on the
250 first partition on the second disk.
251 Note that this only covers permanent local filesystem mappings, not
253 things like network shares. Furthermore NTFS volume mount points may
254 not be listed here.
255 <icon>
257 Virt-inspector2 is sometimes able to extract an icon or logo for the
258 guest. The icon is returned as base64-encoded PNG data. Note that the
259 icon can be very large and high quality.
260 <operatingsystems>
262 <operatingsystem>
263 ...
264 <icon>
265 iVBORw0KGgoAAAANSUhEUgAAAGAAAABg[.......]
266 [... many lines of base64 data ...]
267 </icon>
268 To display the icon, you have to extract it and convert the base64 data
270 back to a binary file. Use an XPath query or simply an editor to
271 extract the data, then use the coreutils base64(1) program to do the
272 conversion back to a PNG file:
273 base64 -i -d < icon.data > icon.png
275 INSPECTING INSTALL DISKS, LIVE CDs
277 Virt-inspector2 can detect some operating system installers on install
278 disks, live CDs, bootable USB keys and more.
279 In this case the <format> tag will contain "installer" and other fields
281 may be present to indicate a live CD, network installer, or one part of
282 a multipart CD. For example:
283 <operatingsystems>
285 <operatingsystem>
286 <root>/dev/sda</root>
287 <name>linux</name>
288 <arch>i386</arch>
289 <distro>ubuntu</distro>
290 <product_name>Ubuntu 10.10 "Maverick Meerkat"</product_name>
291 <major_version>10</major_version>
292 <minor_version>10</minor_version>
293 <format>installer</format>
294 <live/>
295
297 Virt-inspector2 includes built in support for running XPath queries.
298 The reason for including XPath support directly in virt-inspector2 is
299 simply that there are no good and widely available command line
300 programs that can do XPath queries. The only good one is xmlstarlet(1)
301 and that is not available on Red Hat Enterprise Linux.
302 To perform an XPath query, use the --xpath option. Note that in this
304 mode, virt-inspector2 simply reads XML from stdin and outputs the query
305 result on stdout. All other inspection features are disabled in this
306 mode.
307 For example:
309 $ virt-inspector2 -d Guest | virt-inspector2 --xpath '//filesystems'
311 <filesystems>
312 <filesystem dev="/dev/vg_f13x64/lv_root">
313 <type>ext4</type>
314 [...]
315 $ virt-inspector2 -d Guest | \
317 virt-inspector2 --xpath "string(//filesystem[@dev='/dev/sda1']/type)"
318 ext4
319 $ virt-inspector2 -d Guest | \
321 virt-inspector2 --xpath 'string(//icon)' | base64 -i -d | display -
322 [displays the guest icon, if there is one]
323
325 Libvirt guest names can contain arbitrary characters, some of which
326 have meaning to the shell such as "#" and space. You may need to quote
327 or escape these characters on the command line. See the shell manual
328 page sh(1) for details.
329
331 In early versions of libguestfs, virt-inspector2 was a large Perl
332 script that contained many heuristics for inspecting guests. This had
333 several problems: in order to do inspection from other tools (like
334 guestfish) we had to call out to this Perl script; and it privileged
335 Perl over other languages that libguestfs supports.
336 By libguestfs 1.8 we had rewritten the Perl code in C, and incorporated
338 it all into the core libguestfs API (guestfs(3)). Now virt-inspector2
339 is simply a thin C program over the core C API. All of the inspection
340 information is available from all programming languages that libguestfs
341 supports, and from guestfish.
342 For a description of the C inspection API, read "INSPECTION" in
344 guestfs(3).
345 For example code using the C inspection API, look for "inspect-vm.c"
347 which ships with libguestfs.
348 "inspect-vm.c" has also been translated into other languages. For
350 example, "inspect_vm.pl" is the Perl translation, and there are other
351 translations for OCaml, Python, etc. See "USING LIBGUESTFS WITH OTHER
352 PROGRAMMING LANGUAGES" in guestfs(3) for a list of man pages which
353 contain this example code.
354 GETTING INSPECTION DATA FROM GUESTFISH
356 If you use the guestfish -i option, then the main C inspection API
357 "guestfs_inspect_os" in guestfs(3) is called. This is equivalent to
358 the guestfish command "inspect-os". You can also call this guestfish
359 command by hand.
360 "inspect-os" performs inspection on the current disk image, returning
362 the list of operating systems found. Each OS is represented by its
363 root filesystem device. In the majority of cases, this command prints
364 nothing (no OSes found), or a single root device, but beware that it
365 can print multiple lines if there are multiple OSes or if there is an
366 install CD attached to the guest.
367 $ guestfish --ro -a F15x32.img
369 ><fs> run
370 ><fs> inspect-os
371 /dev/vg_f15x32/lv_root
372 Using the root device, you can fetch further information about the
374 guest:
375 ><fs> inspect-get-type /dev/vg_f15x32/lv_root
377 linux
378 ><fs> inspect-get-distro /dev/vg_f15x32/lv_root
379 fedora
380 ><fs> inspect-get-major-version /dev/vg_f15x32/lv_root
381 15
382 ><fs> inspect-get-product-name /dev/vg_f15x32/lv_root
383 Fedora release 15 (Lovelock)
384 Limitations of guestfish make it hard to assign the root device to a
386 variable (since guestfish doesn't have variables), so if you want to do
387 this reproducibly you are better off writing a script using one of the
388 other languages that the libguestfs API supports.
389 To list applications, you have to first mount up the disks:
391 ><fs> inspect-get-mountpoints /dev/vg_f15x32/lv_root
393 /: /dev/vg_f15x32/lv_root
394 /boot: /dev/vda1
395 ><fs> mount-ro /dev/vg_f15x32/lv_root /
396 ><fs> mount-ro /dev/vda1 /boot
397 and then call the inspect-list-applications API:
399 ><fs> inspect-list-applications /dev/vg_f15x32/lv_root | head -28
401 [0] = {
402 app_name: ConsoleKit
403 app_display_name:
404 app_epoch: 0
405 app_version: 0.4.5
406 app_release: 1.fc15
407 app_install_path:
408 app_trans_path:
409 app_publisher:
410 app_url:
411 app_source_package:
412 app_summary:
413 app_description:
414 }
415 [1] = {
416 app_name: ConsoleKit-libs
417 app_display_name:
418 app_epoch: 0
419 app_version: 0.4.5
420 app_release: 1.fc15
421 app_install_path:
422 app_trans_path:
423 app_publisher:
424 app_url:
425 app_source_package:
426 app_summary:
427 app_description:
428 }
429 To display an icon for the guest, note that filesystems must also be
431 mounted as above. You can then do:
432 ><fs> inspect-get-icon /dev/vg_f15x32/lv_root | display -
434
436 This program returns 0 if successful, or non-zero if there was an
437 error.
438
440 guestfs(3), guestfish(1), http://www.w3.org/TR/xpath/, base64(1),
441 xmlstarlet(1), http://libguestfs.org/.
442
444 · Richard W.M. Jones http://people.redhat.com/~rjones/
445 · Matthew Booth mbooth@redhat.com
447
449 Copyright (C) 2010-2012 Red Hat Inc.
450
452 This program is free software; you can redistribute it and/or modify it
453 under the terms of the GNU General Public License as published by the
454 Free Software Foundation; either version 2 of the License, or (at your
455 option) any later version.
456 This program is distributed in the hope that it will be useful, but
458 WITHOUT ANY WARRANTY; without even the implied warranty of
459 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
460 General Public License for more details.
461 You should have received a copy of the GNU General Public License along
463 with this program; if not, write to the Free Software Foundation, Inc.,
464 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
465
467 To get a list of bugs against libguestfs, use this link:
468 https://bugzilla.redhat.com/buglist.cgi?component=libguestfs&product=Virtualization+Tools
469 To report a new bug against libguestfs, use this link:
471 https://bugzilla.redhat.com/enter_bug.cgi?component=libguestfs&product=Virtualization+Tools
472 When reporting a bug, please supply:
474 · The version of libguestfs.
476 · Where you got libguestfs (eg. which Linux distro, compiled from
478 source, etc)
479 · Describe the bug accurately and give a way to reproduce it.
481 · Run libguestfs-test-tool(1) and paste the complete, unedited output
483 into the bug report.
484libguestfs-1.20.11 2013-08-27 virt-inspector2(1)