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