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