1virt-inspector(1) Virtualization Support virt-inspector(1)
2
6 virt-inspector - Display operating system version and other information
7 about a virtual machine
8
10 virt-inspector [--options] -d domname
11 virt-inspector [--options] -a disk.img [-a disk.img ...]
13 Old-style:
15 virt-inspector domname
17 virt-inspector disk.img [disk.img ...]
19
21 virt-inspector 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-inspector produces XML output for feeding into other programs.
26 In the normal usage, use "virt-inspector -d domname" where "domname" is
28 the libvirt domain (see: "virsh list --all").
29 You can also run virt-inspector directly on disk images from a single
31 virtual machine. Use "virt-inspector -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-inspector on install disks, live CDs, bootable
37 USB keys and similar.
38 Virt-inspector can only inspect and report upon one domain at a time.
40 To inspect several virtual machines, you have to run virt-inspector
41 several times (for example, from a shell script for-loop).
42 Because virt-inspector needs direct access to guest images, it won’t
44 normally work over remote libvirt connections.
45 All of the information available from virt-inspector 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 -a URI
66 --add URI
67 Add a remote disk. See "ADDING REMOTE STORAGE" in guestfish(1).
68 --blocksize=512
70 --blocksize=4096
71 --blocksize
72 This parameter sets the sector size of the disk image. It affects
73 all explicitly added subsequent disks after this parameter. Using
74 --blocksize with no argument switches the disk sector size to the
75 default value which is usually 512 bytes. See also
76 "guestfs_add_drive_opts" in guestfs(3).
77 -c URI
79 --connect URI
80 If using libvirt, connect to the given URI. If omitted, then we
81 connect to the default libvirt hypervisor.
82 Libvirt is only used if you specify a "domname" on the command
84 line. If you specify guest block devices directly (-a), then
85 libvirt is not used at all.
86 -d guest
88 --domain guest
89 Add all the disks from the named libvirt guest. Domain UUIDs can
90 be used instead of names.
91 --echo-keys
93 When prompting for keys and passphrases, virt-inspector normally
94 turns echoing off so you cannot see what you are typing. If you
95 are not worried about Tempest attacks and there is no one else in
96 the room you can specify this flag to see what you are typing.
97 --format=raw|qcow2|..
99 --format
100 Specify the format of disk images given on the command line. If
101 this is omitted then the format is autodetected from the content of
102 the disk image.
103 If disk images are requested from libvirt, then this program asks
105 libvirt for this information. In this case, the value of the
106 format parameter is ignored.
107 If working with untrusted raw-format guest disk images, you should
109 ensure the format is always specified.
110 --key SELECTOR
112 Specify a key for LUKS, to automatically open a LUKS device when
113 using the inspection. "ID" can be either the libguestfs device
114 name, or the UUID of the LUKS device.
115 --key "ID":key:KEY_STRING
117 Use the specified "KEY_STRING" as passphrase.
118 --key "ID":file:FILENAME
120 Read the passphrase from FILENAME.
121 --key "ID":clevis
123 Attempt passphrase-less unlocking for "ID" with Clevis, over
124 the network. Please refer to "ENCRYPTED DISKS" in guestfs(3)
125 for more information on network-bound disk encryption (NBDE).
126 Note that if any such option is present on the command line,
128 QEMU user networking will be automatically enabled for the
129 libguestfs appliance.
130 --keys-from-stdin
132 Read key or passphrase parameters from stdin. The default is to
133 try to read passphrases from the user by opening /dev/tty.
134 If there are multiple encrypted devices then you may need to supply
136 multiple keys on stdin, one per line.
137 --no-applications
139 By default the output of virt-inspector includes the list of all
140 the applications installed in the guest, if available.
141 Specify this option to disable this part of the resulting XML.
143 --no-icon
145 By default the output of virt-inspector includes the icon of the
146 guest, if available (see "icon").
147 Specify this option to disable this part of the resulting XML.
149 -v
151 --verbose
152 Enable verbose messages for debugging.
153 -V
155 --version
156 Display version number and exit.
157 -x Enable tracing of libguestfs API calls.
159 --xpath query
161 Perform an XPath query on the XML on stdin, and print the result on
162 stdout. In this mode virt-inspector simply runs an XPath query;
163 all other inspection functions are disabled. See "XPATH QUERIES"
164 below for some examples.
165
167 Previous versions of virt-inspector allowed you to write either:
168 virt-inspector disk.img [disk.img ...]
170 or
172 virt-inspector guestname
174 whereas in this version you should use -a or -d respectively to avoid
176 the confusing case where a disk image might have the same name as a
177 guest.
178 For compatibility the old style is still supported.
180
182 The virt-inspector XML is described precisely in a RELAX NG schema file
183 virt-inspector.rng which is supplied with libguestfs. This section is
184 just an overview.
185 The top-level element is <operatingsystems>, and it contains one or
187 more <operatingsystem> elements. You would only see more than one
188 <operatingsystem> element if the virtual machine is multi-boot, which
189 is vanishingly rare in real world VMs.
190 <operatingsystem>
192 In the <operatingsystem> tag are various optional fields that describe
193 the operating system, its architecture, the descriptive "product name"
194 string, the type of OS and so on, as in this example:
195 <operatingsystems>
197 <operatingsystem>
198 <root>/dev/sda2</root>
199 <name>windows</name>
200 <arch>i386</arch>
201 <distro>windows</distro>
202 <product_name>Windows 7 Enterprise</product_name>
203 <product_variant>Client</product_variant>
204 <major_version>6</major_version>
205 <minor_version>1</minor_version>
206 <windows_systemroot>/Windows</windows_systemroot>
207 In brief, <name> is the class of operating system (something like
209 "linux" or "windows"), <distro> is the distribution (eg. "fedora" but
210 many other distros are recognized) and <arch> is the guest
211 architecture. The other fields are fairly self-explanatory, but
212 because these fields are taken directly from the libguestfs inspection
213 API you can find precise information from "INSPECTION" in guestfs(3).
214 The <root> element is the root filesystem device, but from the point of
216 view of libguestfs (block devices may have completely different names
217 inside the VM itself).
218 <mountpoints>
220 Un*x-like guests typically have multiple filesystems which are mounted
221 at various mountpoints, and these are described in the <mountpoints>
222 element which looks like this:
223 <operatingsystems>
225 <operatingsystem>
226 ...
227 <mountpoints>
228 <mountpoint dev="/dev/vg_f13x64/lv_root">/</mountpoint>
229 <mountpoint dev="/dev/sda1">/boot</mountpoint>
230 </mountpoints>
231 As with <root>, devices are from the point of view of libguestfs, and
233 may have completely different names inside the guest. Only mountable
234 filesystems appear in this list, not things like swap devices.
235 <filesystems>
237 <filesystems> is like <mountpoints> but covers all filesystems
238 belonging to the guest, including swap and empty partitions. (In the
239 rare case of a multi-boot guest, it covers filesystems belonging to
240 this OS or shared with this OS and other OSes).
241 You might see something like this:
243 <operatingsystems>
245 <operatingsystem>
246 ...
247 <filesystems>
248 <filesystem dev="/dev/vg_f13x64/lv_root">
249 <type>ext4</type>
250 <label>Fedora-13-x86_64</label>
251 <uuid>e6a4db1e-15c2-477b-ac2a-699181c396aa</uuid>
252 </filesystem>
253 The optional elements within <filesystem> are the filesystem type, the
255 label, and the UUID.
256 <applications>
258 The related elements <package_format>, <package_management> and
259 <applications> describe applications installed in the virtual machine.
260 <package_format>, if present, describes the packaging system used.
262 Typical values would be "rpm" and "deb".
263 <package_management>, if present, describes the package manager.
265 Typical values include "yum", "up2date" and "apt"
266 <applications> lists the packages or applications installed.
268 <operatingsystems>
270 <operatingsystem>
271 ...
272 <applications>
273 <application>
274 <name>coreutils</name>
275 <version>8.5</version>
276 <release>1</release>
277 </application>
278 The version and release fields may not be available for some types
280 guests. Other fields are possible, see
281 "guestfs_inspect_list_applications" in guestfs(3).
282 <drive_mappings>
284 For operating systems like Windows which use drive letters, virt-
285 inspector is able to find out how drive letters map to filesystems.
286 <operatingsystems>
288 <operatingsystem>
289 ...
290 <drive_mappings>
291 <drive_mapping name="C">/dev/sda2</drive_mapping>
292 <drive_mapping name="E">/dev/sdb1</drive_mapping>
293 </drive_mappings>
294 In the example above, drive C maps to the filesystem on the second
296 partition on the first disk, and drive E maps to the filesystem on the
297 first partition on the second disk.
298 Note that this only covers permanent local filesystem mappings, not
300 things like network shares. Furthermore NTFS volume mount points may
301 not be listed here.
302 <icon>
304 Virt-inspector is sometimes able to extract an icon or logo for the
305 guest. The icon is returned as base64-encoded PNG data. Note that the
306 icon can be very large and high quality.
307 <operatingsystems>
309 <operatingsystem>
310 ...
311 <icon>
312 iVBORw0KGgoAAAANSUhEUgAAAGAAAABg[.......]
313 [... many lines of base64 data ...]
314 </icon>
315 To display the icon, you have to extract it and convert the base64 data
317 back to a binary file. Use an XPath query or simply an editor to
318 extract the data, then use the coreutils base64(1) program to do the
319 conversion back to a PNG file:
320 base64 -i -d < icon.data > icon.png
322
324 Virt-inspector includes built in support for running XPath queries.
325 The reason for including XPath support directly in virt-inspector is
326 simply that there are no good and widely available command line
327 programs that can do XPath queries. The only good one is xmlstarlet(1)
328 and that is not available on Red Hat Enterprise Linux.
329 To perform an XPath query, use the --xpath option. Note that in this
331 mode, virt-inspector simply reads XML from stdin and outputs the query
332 result on stdout. All other inspection features are disabled in this
333 mode.
334 For example:
336 $ virt-inspector -d Guest | virt-inspector --xpath '//filesystems'
338 <filesystems>
339 <filesystem dev="/dev/vg_f13x64/lv_root">
340 <type>ext4</type>
341 [...]
342 $ virt-inspector -d Guest | \
344 virt-inspector --xpath "string(//filesystem[@dev='/dev/sda1']/type)"
345 ext4
346 $ virt-inspector -d Guest | \
348 virt-inspector --xpath 'string(//icon)' | base64 -i -d | display -
349 [displays the guest icon, if there is one]
350
352 In early versions of libguestfs, virt-inspector was a large Perl script
353 that contained many heuristics for inspecting guests. This had several
354 problems: in order to do inspection from other tools (like guestfish)
355 we had to call out to this Perl script; and it privileged Perl over
356 other languages that libguestfs supports.
357 By libguestfs 1.8 we had rewritten the Perl code in C, and incorporated
359 it all into the core libguestfs API (guestfs(3)). Now virt-inspector
360 is simply a thin C program over the core C API. All of the inspection
361 information is available from all programming languages that libguestfs
362 supports, and from guestfish.
363 For a description of the C inspection API, read "INSPECTION" in
365 guestfs(3).
366 For example code using the C inspection API, look for inspect-vm.c
368 which ships with libguestfs.
369 inspect-vm.c has also been translated into other languages. For
371 example, inspect_vm.pl is the Perl translation, and there are other
372 translations for OCaml, Python, etc. See "USING LIBGUESTFS WITH OTHER
373 PROGRAMMING LANGUAGES" in guestfs(3) for a list of man pages which
374 contain this example code.
375 GETTING INSPECTION DATA FROM GUESTFISH
377 If you use the guestfish -i option, then the main C inspection API
378 "guestfs_inspect_os" in guestfs(3) is called. This is equivalent to
379 the guestfish command "inspect-os". You can also call this guestfish
380 command by hand.
381 "inspect-os" performs inspection on the current disk image, returning
383 the list of operating systems found. Each OS is represented by its
384 root filesystem device. In the majority of cases, this command prints
385 nothing (no OSes found), or a single root device, but beware that it
386 can print multiple lines if there are multiple OSes or if there is an
387 install CD attached to the guest.
388 $ guestfish --ro -a F15x32.img
390 ><fs> run
391 ><fs> inspect-os
392 /dev/vg_f15x32/lv_root
393 Using the root device, you can fetch further information about the
395 guest:
396 ><fs> inspect-get-type /dev/vg_f15x32/lv_root
398 linux
399 ><fs> inspect-get-distro /dev/vg_f15x32/lv_root
400 fedora
401 ><fs> inspect-get-major-version /dev/vg_f15x32/lv_root
402 15
403 ><fs> inspect-get-product-name /dev/vg_f15x32/lv_root
404 Fedora release 15 (Lovelock)
405 Limitations of guestfish make it hard to assign the root device to a
407 variable (since guestfish doesn't have variables), so if you want to do
408 this reproducibly you are better off writing a script using one of the
409 other languages that the libguestfs API supports.
410 To list applications, you have to first mount up the disks:
412 ><fs> inspect-get-mountpoints /dev/vg_f15x32/lv_root
414 /: /dev/vg_f15x32/lv_root
415 /boot: /dev/vda1
416 ><fs> mount-ro /dev/vg_f15x32/lv_root /
417 ><fs> mount-ro /dev/vda1 /boot
418 and then call the inspect-list-applications API:
420 ><fs> inspect-list-applications /dev/vg_f15x32/lv_root | head -28
422 [0] = {
423 app_name: ConsoleKit
424 app_display_name:
425 app_epoch: 0
426 app_version: 0.4.5
427 app_release: 1.fc15
428 app_install_path:
429 app_trans_path:
430 app_publisher:
431 app_url:
432 app_source_package:
433 app_summary:
434 app_description:
435 }
436 [1] = {
437 app_name: ConsoleKit-libs
438 app_display_name:
439 app_epoch: 0
440 app_version: 0.4.5
441 app_release: 1.fc15
442 app_install_path:
443 app_trans_path:
444 app_publisher:
445 app_url:
446 app_source_package:
447 app_summary:
448 app_description:
449 }
450 To display an icon for the guest, note that filesystems must also be
452 mounted as above. You can then do:
453 ><fs> inspect-get-icon /dev/vg_f15x32/lv_root | display -
455
457 As described above, early versions of libguestfs shipped with a
458 different virt-inspector program written in Perl (the current version
459 is written in C). The XML output of the Perl virt-inspector was
460 different and it could also output in other formats like text.
461 The old virt-inspector is no longer supported or shipped with
463 libguestfs.
464 To confuse matters further, in Red Hat Enterprise Linux 6 we ship two
466 versions of virt-inspector with different names:
467 virt-inspector Old Perl version.
469 virt-inspector2 New C version.
470
472 This program returns 0 if successful, or non-zero if there was an
473 error.
474
476 guestfs(3), guestfish(1), http://www.w3.org/TR/xpath/, base64(1),
477 xmlstarlet(1), http://libguestfs.org/.
478
480 • Richard W.M. Jones http://people.redhat.com/~rjones/
481 • Matthew Booth mbooth@redhat.com
483
485 Copyright (C) 2010-2012 Red Hat Inc.
486
488 This program is free software; you can redistribute it and/or modify it
489 under the terms of the GNU General Public License as published by the
490 Free Software Foundation; either version 2 of the License, or (at your
491 option) any later version.
492 This program is distributed in the hope that it will be useful, but
494 WITHOUT ANY WARRANTY; without even the implied warranty of
495 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
496 General Public License for more details.
497 You should have received a copy of the GNU General Public License along
499 with this program; if not, write to the Free Software Foundation, Inc.,
500 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
501
503 To get a list of bugs against libguestfs, use this link:
504 https://bugzilla.redhat.com/buglist.cgi?component=libguestfs&product=Virtualization+Tools
505 To report a new bug against libguestfs, use this link:
507 https://bugzilla.redhat.com/enter_bug.cgi?component=libguestfs&product=Virtualization+Tools
508 When reporting a bug, please supply:
510 • The version of libguestfs.
512 • Where you got libguestfs (eg. which Linux distro, compiled from
514 source, etc)
515 • Describe the bug accurately and give a way to reproduce it.
517 • Run libguestfs-test-tool(1) and paste the complete, unedited output
519 into the bug report.
520guestfs-tools-1.49.7 2022-12-10 virt-inspector(1)