1virt-v2v(1) Virtualization Support virt-v2v(1)
2
6 virt-v2v - Convert a guest to use KVM
7
9 virt-v2v -ic vpx://vcenter.example.com/Datacenter/esxi vmware_guest
10 virt-v2v -i libvirtxml guest-domain.xml -o local -os /var/tmp
12 virt-v2v -i disk disk.img -o local -os /var/tmp
14 virt-v2v -i disk disk.img -o glance
16 virt-v2v -ic vpx://vcenter.example.com/Datacenter/esxi vmware_guest \
18 -o rhv-upload -oc https://ovirt-engine.example.com/ovirt-engine/api \
19 -os ovirt-data -op /tmp/ovirt-admin-password -of raw \
20 -oo rhv-cafile=/tmp/ca.pem -oo rhv-direct \
21 --bridge ovirtmgmt
22
24 Virt-v2v converts guests from a foreign hypervisor to run on KVM. It
25 can read Linux and Windows guests running on VMware, Xen, Hyper-V and
26 some other hypervisors, and convert them to KVM managed by libvirt,
27 OpenStack, oVirt, Red Hat Virtualisation (RHV) or several other
28 targets.
29 There is also a companion front-end called virt-p2v(1) which comes as
31 an ISO, CD or PXE image that can be booted on physical machines to
32 virtualize those machines (physical to virtual, or p2v).
33 This manual page documents the rewritten virt-v2v included in
35 libguestfs ≥ 1.28.
36
38 Convert from VMware vCenter server to local libvirt
39 You have a VMware vCenter server called "vcenter.example.com", a
40 datacenter called "Datacenter", and an ESXi hypervisor called "esxi".
41 You want to convert a guest called "vmware_guest" to run locally under
42 libvirt.
43 virt-v2v -ic vpx://vcenter.example.com/Datacenter/esxi vmware_guest
45 In this case you will most likely have to run virt-v2v as "root", since
47 it needs to talk to the system libvirt daemon and copy the guest disks
48 to /var/lib/libvirt/images.
49 For more information see "INPUT FROM VMWARE VCENTER SERVER" below.
51 Convert from VMware to RHV/oVirt
53 This is the same as the previous example, except you want to send the
54 guest to a RHV Data Domain using the RHV REST API. Guest network
55 interface(s) are connected to the target network called "ovirtmgmt".
56 virt-v2v -ic vpx://vcenter.example.com/Datacenter/esxi vmware_guest \
58 -o rhv-upload -oc https://ovirt-engine.example.com/ovirt-engine/api \
59 -os ovirt-data -op /tmp/ovirt-admin-password -of raw \
60 -oo rhv-cafile=/tmp/ca.pem -oo rhv-direct \
61 --bridge ovirtmgmt
62 In this case the host running virt-v2v acts as a conversion server.
64 For more information see "OUTPUT TO RHV" below.
66 Convert from ESXi hypervisor over SSH to local libvirt
68 You have an ESXi hypervisor called "esxi.example.com" with SSH access
69 enabled. You want to convert from VMFS storage on that server to a
70 local file.
71 virt-v2v \
73 -i vmx -it ssh \
74 "ssh://root@esxi.example.com/vmfs/volumes/datastore1/guest/guest.vmx" \
75 -o local -os /var/tmp
76 The guest must not be running. Virt-v2v would not need to be run as
78 root in this case.
79 For more information about converting from VMX files see "INPUT FROM
81 VMWARE VMX" below.
82 Convert disk image to OpenStack glance
84 Given a disk image from another hypervisor that you want to convert to
85 run on OpenStack (only KVM-based OpenStack is supported), you can do:
86 virt-v2v -i disk disk.img -o glance
88 See "OUTPUT TO GLANCE" below.
90 Convert disk image to disk image
92 Given a disk image from another hypervisor that you want to convert to
93 run on KVM, you have two options. The simplest way is to try:
94 virt-v2v -i disk disk.img -o local -os /var/tmp
96 where virt-v2v guesses everything about the input disk.img and (in this
98 case) writes the converted result to /var/tmp.
99 A more complex method is to write some libvirt XML describing the input
101 guest (if you can get the source hypervisor to provide you with libvirt
102 XML, then so much the better). You can then do:
103 virt-v2v -i libvirtxml guest-domain.xml -o local -os /var/tmp
105 Since guest-domain.xml contains the path(s) to the guest disk image(s)
107 you do not need to specify the name of the disk image on the command
108 line.
109
111 ┌────────────┐ ┌─────────▶ -o null
112 -i disk ────────────┐ │ │ ─┘┌───────▶ -o local
113 -i ova ──────────┐ └──▶ │ virt-v2v │ ──┘┌───────▶ -o qemu
114 └────▶ │ conversion │ ───┘┌────────────┐
115 VMware─▶┌────────────┐ │ server │ ────▶ -o libvirt │─▶ KVM
116 Xen ───▶│ -i libvirt ──▶ │ │ │ (default) │
117 ... ───▶│ (default) │ │ │ ──┐ └────────────┘
118 └────────────┘ │ │ ─┐└──────▶ -o glance
119 -i libvirtxml ─────────▶ │ │ ┐├─────────▶ -o rhv
120 -i vmx ────────────────▶ │ │ │└─────────▶ -o vdsm
121 └────────────┘ └──────────▶ -o rhv-upload
122 Virt-v2v has a number of possible input and output modes, selected
124 using the -i and -o options. Only one input and output mode can be
125 selected for each run of virt-v2v.
126 -i disk is used for reading from local disk images (mainly for
128 testing).
129 -i libvirt is used for reading from any libvirt source. Since libvirt
131 can connect to many different hypervisors, it is used for reading
132 guests from VMware, RHEL 5 Xen and more. The -ic option selects the
133 precise libvirt source.
134 -i libvirtxml is used to read from libvirt XML files. This is the
136 method used by virt-p2v(1) behind the scenes.
137 -i ova is used for reading from a VMware ova source file.
139 -i vmx is used for reading from a VMware vmx file.
141 -o glance is used for writing to OpenStack Glance.
143 -o libvirt is used for writing to any libvirt target. Libvirt can
145 connect to local or remote KVM hypervisors. The -oc option selects the
146 precise libvirt target.
147 -o local is used to write to a local disk image with a local libvirt
149 configuration file (mainly for testing).
150 -o qemu writes to a local disk image with a shell script for booting
152 the guest directly in qemu (mainly for testing).
153 -o rhv-upload is used to write to a RHV / oVirt target. -o rhv is a
155 legacy method to write to RHV / oVirt < 4.2. -o vdsm is only used when
156 virt-v2v runs under VDSM control.
157
159 --help
160 Display help.
161 -b ...
163 --bridge ...
164 See --network below.
165 --colors
167 --colours
168 Use ANSI colour sequences to colourize messages. This is the
169 default when the output is a tty. If the output of the program is
170 redirected to a file, ANSI colour sequences are disabled unless you
171 use this option.
172 --compressed
174 Write a compressed output file. This is only allowed if the output
175 format is qcow2 (see -of below), and is equivalent to the -c option
176 of qemu-img(1).
177 --debug-overlays
179 Save the overlay file(s) created during conversion. This option is
180 only used for debugging virt-v2v and may be removed in a future
181 version.
182 --echo-keys
184 When prompting for keys and passphrases, virt-v2v normally turns
185 echoing off so you cannot see what you are typing. If you are not
186 worried about Tempest attacks and there is no one else in the room
187 you can specify this flag to see what you are typing.
188 Note this options only applies to keys and passphrases for
190 encrypted devices and partitions, not for passwords used to connect
191 to remote servers.
192 -i disk
194 Set the input method to disk.
195 In this mode you can read a virtual machine disk image with no
197 metadata. virt-v2v tries to guess the best default metadata. This
198 is usually adequate but you can get finer control (eg. of memory
199 and vCPUs) by using -i libvirtxml instead. Only guests that use a
200 single disk can be imported this way.
201 -i libvirt
203 Set the input method to libvirt. This is the default.
204 In this mode you have to specify a libvirt guest name or UUID on
206 the command line. You may also specify a libvirt connection URI
207 (see -ic).
208 -i libvirtxml
210 Set the input method to libvirtxml.
211 In this mode you have to pass a libvirt XML file on the command
213 line. This file is read in order to get metadata about the source
214 guest (such as its name, amount of memory), and also to locate the
215 input disks. See "MINIMAL XML FOR -i libvirtxml OPTION" below.
216 -i local
218 This is the same as -i disk.
219 -i ova
221 Set the input method to ova.
222 In this mode you can read a VMware ova file. Virt-v2v will read
224 the ova manifest file and check the vmdk volumes for validity
225 (checksums) as well as analyzing the ovf file, and then convert the
226 guest. See "INPUT FROM VMWARE OVA" below
227 -i vmx
229 Set the input method to vmx.
230 In this mode you can read a VMware vmx file directly or over SSH.
232 This is useful when VMware VMs are stored on an NFS server which
233 you can mount directly, or where you have access by SSH to an ESXi
234 hypervisor. See "INPUT FROM VMWARE VMX" below
235 -ic libvirtURI
237 Specify a libvirt connection URI to use when reading the guest.
238 This is only used when -i libvirt.
239 Only local libvirt connections, VMware vCenter connections, or RHEL
241 5 Xen remote connections can be used. Other remote libvirt
242 connections will not work in general.
243 See also "INPUT FROM VMWARE VCENTER SERVER", "INPUT FROM XEN"
245 below.
246 -if format
248 For -i disk only, this specifies the format of the input disk
249 image. For other input methods you should specify the input format
250 in the metadata.
251 -io OPTION=VALUE
253 Set input option(s) related to the current input mode or transport.
254 To display short help on what options are available you can use:
255 virt-v2v -it vddk -io "?"
257 -io vddk-libdir=LIBDIR
259 Set the VDDK library directory. This directory should contain
260 subdirectories called include, lib64 etc., but do not include lib64
261 actually in the parameter.
262 In most cases this parameter is required when using the -it vddk
264 (VDDK) transport. See "INPUT FROM VDDK" below for details.
265 -io vddk-thumbprint=xx:xx:xx:...
267 Set the thumbprint of the remote VMware server.
268 This parameter is required when using the -it vddk (VDDK)
270 transport. See "INPUT FROM VDDK" below for details.
271 -io vddk-config=FILENAME
273 -io vddk-cookie=COOKIE
274 -io vddk-nfchostport=PORT
275 -io vddk-port=PORT
276 -io vddk-snapshot=SNAPSHOT-MOREF
277 -io vddk-transports=MODE:MODE:...
278 -io vddk-vimapiver=APIVER
279 When using VDDK mode, these options are passed unmodified to the
280 nbdkit(1) VDDK plugin. Please refer to nbdkit-vddk-plugin(1).
281 These are all optional.
282 -it ssh
284 When using -i vmx, this enables the ssh transport. See "INPUT FROM
285 VMWARE VMX" below.
286 -it vddk
288 Use VMware VDDK as a transport to copy the input disks. See "INPUT
289 FROM VDDK" below. If you use this parameter then you may need to
290 use other -io vddk* options to specify how to connect through VDDK.
291 --keys-from-stdin
293 Read key or passphrase parameters from stdin. The default is to
294 try to read passphrases from the user by opening /dev/tty.
295 Note this options only applies to keys and passphrases for
297 encrypted devices and partitions, not for passwords used to connect
298 to remote servers.
299 --machine-readable
301 This option is used to make the output more machine friendly when
302 being parsed by other programs. See "MACHINE READABLE OUTPUT"
303 below.
304 -n in:out
306 -n out
307 --network in:out
308 --network out
309 -b in:out
310 -b out
311 --bridge in:out
312 --bridge out
313 Map network (or bridge) called "in" to network (or bridge) called
314 "out". If no "in:" prefix is given, all other networks (or
315 bridges) are mapped to "out".
316 See "NETWORKS AND BRIDGES" below.
318 --no-copy
320 Don’t copy the disks. Instead, conversion is performed (and thrown
321 away), and metadata is written, but no disks are created. See also
322 discussion of -o null below.
323 This is useful in two cases: Either you want to test if conversion
325 is likely to succeed, without the long copying process. Or you are
326 only interested in looking at the metadata.
327 This option is not compatible with -o libvirt since it would create
329 a faulty guest (one with no disks).
330 This option is not compatible with -o glance for technical reasons.
332 -o disk
334 This is the same as -o local.
335 -o glance
337 Set the output method to OpenStack Glance. In this mode the
338 converted guest is uploaded to Glance. See "OUTPUT TO GLANCE"
339 below.
340 -o libvirt
342 Set the output method to libvirt. This is the default.
343 In this mode, the converted guest is created as a libvirt guest.
345 You may also specify a libvirt connection URI (see -oc).
346 See "OUTPUT TO LIBVIRT" below.
348 -o local
350 Set the output method to local.
351 In this mode, the converted guest is written to a local directory
353 specified by -os /dir (the directory must exist). The converted
354 guest’s disks are written as:
355 /dir/name-sda
357 /dir/name-sdb
358 [etc]
359 and a libvirt XML file is created containing guest metadata:
361 /dir/name.xml
363 where "name" is the guest name.
365 -o null
367 Set the output method to null.
368 The guest is converted and copied (unless you also specify
370 --no-copy), but the results are thrown away and no metadata is
371 written.
372 -o ovirt
374 This is the same as -o rhv.
375 -o ovirt-upload
377 This is the same as -o rhv-upload.
378 -o qemu
380 Set the output method to qemu.
381 This is similar to -o local, except that a shell script is written
383 which you can use to boot the guest in qemu. The converted disks
384 and shell script are written to the directory specified by -os.
385 -o rhev
387 This is the same as -o rhv.
388 -o rhv
390 Set the output method to rhv.
391 The converted guest is written to a RHV Export Storage Domain. The
393 -os parameter must also be used to specify the location of the
394 Export Storage Domain. Note this does not actually import the
395 guest into RHV. You have to do that manually later using the UI.
396 See "OUTPUT TO RHV (OLD METHOD)" below.
398 -o rhv-upload
400 Set the output method to rhv-upload.
401 The converted guest is written directly to a RHV Data Domain. This
403 is a faster method than -o rhv, but requires oVirt or RHV ≥ 4.2.
404 See "OUTPUT TO RHV" below.
406 -o vdsm
408 Set the output method to vdsm.
409 This mode is similar to -o rhv, but the full path to the data
411 domain must be given:
412 /rhv/data-center/<data-center-uuid>/<data-domain-uuid>. This mode
413 is only used when virt-v2v runs under VDSM control.
414 -oa sparse
416 -oa preallocated
417 Set the output file allocation mode. The default is "sparse".
418 -oc URI
420 Specify a connection URI to use when writing the converted guest.
421 For -o libvirt this is the libvirt URI. Only local libvirt
423 connections can be used. Remote libvirt connections will not work.
424 See "OUTPUT TO LIBVIRT" below for further information.
425 -of format
427 When converting the guest, convert the disks to the given format.
428 If not specified, then the input format is used.
430 -on name
432 Rename the guest when converting it. If this option is not used
433 then the output name is the same as the input name.
434 -oo OPTION=VALUE
436 Set output option(s) related to the current output mode. To
437 display short help on what options are available you can use:
438 virt-v2v -o rhv-upload -oo "?"
440 -oo rhv-cafile=ca.pem
442 For -o rhv-upload ("OUTPUT TO RHV") only, the ca.pem file
443 (Certificate Authority), copied from /etc/pki/ovirt-engine/ca.pem
444 on the oVirt engine.
445 -oo rhv-cluster="CLUSTERNAME"
447 For -o rhv-upload ("OUTPUT TO RHV") only, set the RHV Cluster Name.
448 If not given it uses "Default".
449 -oo rhv-direct
451 For -o rhv-upload ("OUTPUT TO RHV") only, if this option is given
452 then virt-v2v will attempt to directly upload the disk to the oVirt
453 node, otherwise it will proxy the upload through the oVirt engine.
454 Direct upload requires that you have network access to the oVirt
455 nodes. Non-direct upload is slightly slower but should work in all
456 situations.
457 -oo rhv-verifypeer
459 For -o rhv-upload ("OUTPUT TO RHV") only, verify the oVirt/RHV
460 server’s identity by checking the server‘s certificate against the
461 Certificate Authority.
462 -oo vdsm-compat=0.10
464 -oo vdsm-compat=1.1
465 If -o vdsm and the output format is qcow2, then we add the qcow2
466 compat=0.10 option to the output file for compatibility with RHEL 6
467 (see https://bugzilla.redhat.com/1145582).
468 If -oo vdsm-compat=1.1 is used then modern qcow2 (compat=1.1) files
470 are generated instead.
471 Currently -oo vdsm-compat=0.10 is the default, but this will change
473 to -oo vdsm-compat=1.1 in a future version of virt-v2v (when we can
474 assume that everyone is using a modern version of qemu).
475 Note this option only affects -o vdsm output. All other output
477 modes (including -o rhv) generate modern qcow2 compat=1.1 files,
478 always.
479 If this option is available, then "vdsm-compat-option" will appear
481 in the --machine-readable output.
482 -oo vdsm-image-uuid=UUID
484 -oo vdsm-vol-uuid=UUID
485 -oo vdsm-vm-uuid=UUID
486 -oo vdsm-ovf-output=DIR
487 Normally the RHV output mode chooses random UUIDs for the target
488 guest. However VDSM needs to control the UUIDs and passes these
489 parameters when virt-v2v runs under VDSM control. The parameters
490 control:
491 · the image directory of each guest disk (-oo vdsm-image-uuid)
493 (this option is passed once for each guest disk)
494 · UUIDs for each guest disk (-oo vdsm-vol-uuid) (this option is
496 passed once for each guest disk)
497 · the OVF file name (-oo vdsm-vm-uuid).
499 · the OVF output directory (default current directory) (-oo vdsm-
501 ovf-output).
502 The format of UUIDs is: "12345678-1234-1234-1234-123456789abc"
504 (each hex digit can be "0-9" or "a-f"), conforming to OSF DCE 1.1.
505 These options can only be used with -o vdsm.
507 -oo vdsm-ovf-flavour=flavour
509 This option controls the format of the OVF generated at the end of
510 conversion. Currently there are two possible flavours:
511 rhvexp
513 The OVF format used in RHV export storage domain.
514 ovirt
516 The OVF format understood by oVirt REST API.
517 For backward compatibility the default is rhvexp, but this may
519 change in the future.
520 -op file
522 Supply a file containing a password to be used when connecting to
523 the target hypervisor. Note the file should contain the whole
524 password, without any trailing newline, and for security the file
525 should have mode 0600 so that others cannot read it.
526 -os storage
528 The location of the storage for the converted guest.
529 For -o libvirt, this is a libvirt directory pool (see
531 "virsh pool-list") or pool UUID.
532 For -o local and -o qemu, this is a directory name. The directory
534 must exist.
535 For -o rhv-upload, this is the name of the destination Storage
537 Domain.
538 For -o rhv, this can be an NFS path of the Export Storage Domain of
540 the form "<host>:<path>", eg:
541 rhv-storage.example.com:/rhv/export
543 The NFS export must be mountable and writable by the user and host
545 running virt-v2v, since the virt-v2v program has to actually mount
546 it when it runs. So you probably have to run virt-v2v as "root".
547 Or: You can mount the Export Storage Domain yourself, and point -os
549 to the mountpoint. Note that virt-v2v will still need to write to
550 this remote directory, so virt-v2v will still need to run as
551 "root".
552 You will get an error if virt-v2v is unable to mount/write to the
554 Export Storage Domain.
555 --password-file file
557 Instead of asking for password(s) interactively, pass the password
558 through a file. Note the file should contain the whole password,
559 without any trailing newline, and for security the file should have
560 mode 0600 so that others cannot read it.
561 --print-source
563 Print information about the source guest and stop. This option is
564 useful when you are setting up network and bridge maps. See
565 "NETWORKS AND BRIDGES".
566 -q
568 --quiet
569 This disables progress bars and other unnecessary output.
570 --root ask
572 --root single
573 --root first
574 --root /dev/sdX
575 --root /dev/VG/LV
576 Choose the root filesystem to be converted.
577 In the case where the virtual machine is dual-boot or multi-boot,
579 or where the VM has other filesystems that look like operating
580 systems, this option can be used to select the root filesystem
581 (a.k.a. "C:" drive or /) of the operating system that is to be
582 converted. The Windows Recovery Console, certain attached DVD
583 drives, and bugs in libguestfs inspection heuristics, can make a
584 guest look like a multi-boot operating system.
585 The default in virt-v2v ≤ 0.7.1 was --root single, which causes
587 virt-v2v to die if a multi-boot operating system is found.
588 Since virt-v2v ≥ 0.7.2 the default is now --root ask: If the VM is
590 found to be multi-boot, then virt-v2v will stop and list the
591 possible root filesystems and ask the user which to use. This
592 requires that virt-v2v is run interactively.
593 --root first means to choose the first root device in the case of a
595 multi-boot operating system. Since this is a heuristic, it may
596 sometimes choose the wrong one.
597 You can also name a specific root device, eg. --root /dev/sda2
599 would mean to use the second partition on the first hard drive. If
600 the named root device does not exist or was not detected as a root
601 device, then virt-v2v will fail.
602 Note that there is a bug in grub which prevents it from
604 successfully booting a multiboot system if virtio is enabled. Grub
605 is only able to boot an operating system from the first virtio
606 disk. Specifically, /boot must be on the first virtio disk, and it
607 cannot chainload an OS which is not in the first virtio disk.
608 -v
610 --verbose
611 Enable verbose messages for debugging.
612 -V
614 --version
615 Display version number and exit.
616 -x Enable tracing of libguestfs API calls.
618
620 Older versions of virt-v2v could turn a Xen paravirtualized (PV) guest
621 into a KVM guest by installing a new kernel. This version of virt-v2v
622 does not attempt to install any new kernels. Instead it will give you
623 an error if there are only Xen PV kernels available.
624 Therefore before conversion you should check that a regular kernel is
626 installed. For some older Linux distributions, this means installing a
627 kernel from the table below:
628 RHEL 3 (Does not apply, as there was no Xen PV kernel)
630 RHEL 4 i686 with > 10GB of RAM: install 'kernel-hugemem'
632 i686 SMP: install 'kernel-smp'
633 other i686: install 'kernel'
634 x86-64 SMP with > 8 CPUs: install 'kernel-largesmp'
635 x86-64 SMP: install 'kernel-smp'
636 other x86-64: install 'kernel'
637 RHEL 5 i686: install 'kernel-PAE'
639 x86-64: install 'kernel'
640 SLES 10 i586 with > 10GB of RAM: install 'kernel-bigsmp'
642 i586 SMP: install 'kernel-smp'
643 other i586: install 'kernel-default'
644 x86-64 SMP: install 'kernel-smp'
645 other x86-64: install 'kernel-default'
646 SLES 11+ i586: install 'kernel-pae'
648 x86-64: install 'kernel-default'
649 Windows (Does not apply, as there is no Xen PV Windows kernel)
651
653 "Virtio" is the name for a set of drivers which make disk (block
654 device), network and other guest operations work much faster on KVM.
655 Older versions of virt-v2v could install these drivers for certain
657 Linux guests. This version of virt-v2v does not attempt to install new
658 Linux kernels or drivers, but will warn you if they are not installed
659 already.
660 In order to enable virtio, and hence improve performance of the guest
662 after conversion, you should ensure that the minimum versions of
663 packages are installed before conversion, by consulting the table
664 below.
665 RHEL 3 No virtio drivers are available
667 RHEL 4 kernel >= 2.5.9-89.EL
669 lvm2 >= 2.02.42-5.el4
670 device-mapper >= 1.02.28-2.el4
671 selinux-policy-targeted >= 1.17.30-2.152.el4
672 policycoreutils >= 1.18.1-4.13
673 RHEL 5 kernel >= 2.6.18-128.el5
675 lvm2 >= 2.02.40-6.el5
676 selinux-policy-targeted >= 2.4.6-203.el5
677 RHEL 6+ All versions support virtio
679 Fedora All versions support virtio
681 SLES 11+ All versions support virtio
683 SLES 10 kernel >= 2.6.16.60-0.85.1
685 OpenSUSE 11+ All versions support virtio
687 OpenSUSE 10 kernel >= 2.6.25.5-1.1
689 Debian 6+ All versions support virtio
691 Ubuntu 10.04+ All versions support virtio
693 Windows Drivers are installed from the ISO or directory pointed
695 to by "VIRTIO_WIN" environment variable if present
696
698 SELinux relabel appears to hang forever
699 In RHEL ≤ 4.7 there was a bug which causes SELinux relabelling to
700 appear to hang forever at:
701 *** Warning -- SELinux relabel is required. ***
703 *** Disabling security enforcement. ***
704 *** Relabeling could take a very long time, ***
705 *** depending on file system size. ***
706 In reality it is waiting for you to press a key (but there is no visual
708 indication of this). You can either hit the "[Return]" key, at which
709 point the guest will finish relabelling and reboot, or you can install
710 policycoreutils ≥ 1.18.1-4.13 before starting the v2v conversion. See
711 also https://bugzilla.redhat.com/show_bug.cgi?id=244636
712
714 "warning: could not determine a way to update the configuration of Grub2"
715 Currently, virt-v2v has no way to set the default kernel in Debian and
716 Ubuntu guests using GRUB 2 as bootloader. This means that virt-v2v
717 will not change the default kernel used for booting, even in case it is
718 not the best kernel available on the guest. A recommended procedure
719 is, before using virt-v2v, to check that the boot kernel is the best
720 kernel available in the guest (for example by making sure the guest is
721 up-to-date).
722
724 Windows ≥ 8 Fast Startup is incompatible with virt-v2v
725 Guests which use the Windows ≥ 8 "Fast Startup" feature (or guests
726 which are hibernated) cannot be converted with virt-v2v. You will see
727 an error:
728 virt-v2v: error: unable to mount the disk image for writing. This has
730 probably happened because Windows Hibernation or Fast Restart is being
731 used in this guest. You have to disable this (in the guest) in order
732 to use virt-v2v.
733 As the message says, you need to boot the guest and disable the "Fast
735 Startup" feature (Control Panel → Power Options → Choose what the power
736 buttons do → Change settings that are currently unavailable → Turn on
737 fast startup), and shut down the guest, and then you will be able to
738 convert it.
739 For more information, see: "WINDOWS HIBERNATION AND WINDOWS 8 FAST
741 STARTUP" in guestfs(3).
742 Boot failure: 0x0000007B
744 This boot failure is caused by Windows being unable to find or load the
745 right disk driver (eg. viostor.sys). If you experience this error,
746 here are some things to check:
747 · First ensure that the guest boots on the source hypervisor before
749 conversion.
750 · Check you have the Windows virtio drivers available in
752 /usr/share/virtio-win, and that virt-v2v did not print any warning
753 about not being able to install virtio drivers.
754 On Red Hat Enterprise Linux 7, you will need to install the signed
756 drivers available in the "virtio-win" package. If you do not have
757 access to the signed drivers, then you will probably need to
758 disable driver signing in the boot menus.
759 · Check that you are presenting a virtio-blk interface (not virtio-
761 scsi and not ide) to the guest. On the qemu/KVM command line you
762 should see something similar to this:
763 ... -drive file=windows-sda,if=virtio ...
765 In libvirt XML, you should see:
767 <target dev='vda' bus='virtio'/>
769 · Check that Windows Group Policy does not prevent the driver from
771 being installed or used. Try deleting Windows Group Policy before
772 conversion.
773 · Check there is no anti-virus or other software which implements
775 Group Policy-like prohibitions on installing or using new drivers.
776 · Enable boot debugging and check the viostor.sys driver is being
778 loaded.
779 OpenStack and Windows reactivation
781 OpenStack does not offer stable device / PCI addresses to guests.
782 Every time it creates or starts a guest, it regenerates the libvirt XML
783 for that guest from scratch. The libvirt XML will have no <address>
784 fields. Libvirt will then assign addresses to devices, in a
785 predictable manner. Addresses may change if any of the following are
786 true:
787 · A new disk or network device has been added or removed from the
789 guest.
790 · The version of OpenStack or (possibly) libvirt has changed.
792 Because Windows does not like "hardware" changes of this kind, it may
794 trigger Windows reactivation.
795 This can also prevent booting with a 7B error [see previous section] if
797 the guest has group policy containing "Device Installation
798 Restrictions".
799 Support for SHA-2 certificates in Windows 7 and Windows Server 2008 R2
801 Later versions of the Windows virtio drivers are signed using SHA-2
802 certificates (instead of SHA-1). The original shipping Windows 7 and
803 Windows Server 2008 R2 did not understand SHA-2 certificates and so the
804 Windows virtio drivers will not install properly.
805 To fix this you must apply SHA-2 Code Signing Support from:
807 https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2015/3033929
808 before converting the guest.
809 For further information see:
811 https://bugzilla.redhat.com/show_bug.cgi?id=1624878
812
814 VMware allows you to present UEFI firmware to guests (instead of the
815 ordinary PC BIOS). Virt-v2v can convert these guests, but requires
816 that UEFI is supported by the target hypervisor.
817 Currently KVM supports OVMF, an open source UEFI firmware, and can run
819 these guests.
820 Since OVMF support was only recently added to KVM (in 2014/2015), not
822 all target environments support UEFI guests yet:
823 UEFI on libvirt, qemu
825 Supported. Virt-v2v will generate the correct libvirt XML
826 (metadata) automatically, but note that the same version of OVMF
827 must be installed on the conversion host as is installed on the
828 target hypervisor, else you will have to adjust paths in the
829 metadata.
830 On RHEL ≥ 7.3, only qemu-kvm-rhev (not qemu-kvm) is supported.
832 UEFI on OpenStack
834 Not supported.
835 UEFI on RHV
837 Not supported.
838
840 Guests are usually connected to one or more networks, and when
841 converted to the target hypervisor you usually want to reconnect those
842 networks at the destination. The options --network and --bridge allow
843 you to do that.
844 If you are unsure of what networks and bridges are in use on the source
846 hypervisor, then you can examine the source metadata (libvirt XML,
847 vCenter information, etc.). Or you can run virt-v2v with the
848 --print-source option which causes virt-v2v to print out the
849 information it has about the guest on the source and then exit.
850 In the --print-source output you will see a section showing the guest’s
852 Network Interface Cards (NICs):
853 $ virt-v2v [-i ...] --print-source name
855 [...]
856 NICs:
857 Network "default" mac: 52:54:00:d0:cf:0e
858 Bridges are special classes of network devices which are attached to a
860 named external network on the source hypervisor, for example:
861 $ virt-v2v [-i ...] --print-source name
863 [...]
864 NICs:
865 Bridge "br0"
866 To map a specific bridge to a target network, for example "br0" on the
868 source to "ovirtmgmt" on the target, use:
869 virt-v2v [...] --bridge br0:ovirtmgmt
871 To map every bridge to a target network, use:
873 virt-v2v [...] --bridge ovirtmgmt
875
877 Virt-v2v is able to import guests from VMware vCenter Server.
878 vCenter ≥ 5.0 is required. If you don’t have vCenter, using OVA or VMX
880 is recommended instead (see "INPUT FROM VMWARE OVA" and/or "INPUT FROM
881 VMWARE VMX" below), or if that is not possible then see "INPUT FROM
882 VMWARE ESXi HYPERVISOR".
883 Virt-v2v uses libvirt for access to vCenter, and therefore the input
885 mode should be -i libvirt. As this is the default, you don't need to
886 specify it on the command line.
887 VCENTER: REMOVE VMWARE TOOLS FROM WINDOWS GUESTS
889 For Windows guests, you should remove VMware tools before conversion.
890 Although this is not strictly necessary, and the guest will still be
891 able to run, if you don't do this then the converted guest will
892 complain on every boot. The tools cannot be removed after conversion
893 because the uninstaller checks if it is running on VMware and refuses
894 to start (which is also the reason that virt-v2v cannot remove them).
895 This is not necessary for Linux guests, as virt-v2v is able to remove
897 VMware tools.
898 VCENTER: URI
900 The libvirt URI of a vCenter server looks something like this:
901 vpx://user@server/Datacenter/esxi
903 where:
905 "user@"
907 is the (optional, but recommended) user to connect as.
908 If the username contains a backslash (eg. "DOMAIN\USER") then you
910 will need to URI-escape that character using %5c: "DOMAIN%5cUSER"
911 (5c is the hexadecimal ASCII code for backslash.) Other
912 punctuation may also have to be escaped.
913 "server"
915 is the vCenter Server (not hypervisor).
916 "Datacenter"
918 is the name of the datacenter.
919 If the name contains a space, replace it with the URI-escape code
921 %20.
922 "esxi"
924 is the name of the ESXi hypervisor running the guest.
925 If the VMware deployment is using folders, then these may need to be
927 added to the URI, eg:
928 vpx://user@server/Folder/Datacenter/esxi
930 For full details of libvirt URIs, see: http://libvirt.org/drvesx.html
932 Typical errors from libvirt / virsh when the URI is wrong include:
934 · Could not find datacenter specified in [...]
936 · Could not find compute resource specified in [...]
938 · Path [...] does not specify a compute resource
940 · Path [...] does not specify a host system
942 · Could not find host system specified in [...]
944 VCENTER: TEST LIBVIRT CONNECTION TO VCENTER
946 Use the virsh(1) command to list the guests on the vCenter Server like
947 this:
948 $ virsh -c 'vpx://root@vcenter.example.com/Datacenter/esxi' list --all
950 Enter root's password for vcenter.example.com: ***
951 Id Name State
953 ----------------------------------------------------
954 - Fedora 20 shut off
955 - Windows 2003 shut off
956 If you get an error "Peer certificate cannot be authenticated with
958 given CA certificates" or similar, then you can either import the
959 vCenter host’s certificate, or bypass signature verification by adding
960 the "?no_verify=1" flag:
961 $ virsh -c 'vpx://root@vcenter.example.com/Datacenter/esxi?no_verify=1' list --all
963 You should also try dumping the metadata from any guest on your server,
965 like this:
966 $ virsh -c 'vpx://root@vcenter.example.com/Datacenter/esxi' dumpxml "Windows 2003"
968 <domain type='vmware'>
969 <name>Windows 2003</name>
970 [...]
971 </domain>
972 If the above commands do not work, then virt-v2v is not going to work
974 either. Fix your libvirt configuration and/or your VMware vCenter
975 Server before continuing.
976 VCENTER: IMPORTING A GUEST
978 To import a particular guest from vCenter Server, do:
979 $ virt-v2v -ic 'vpx://root@vcenter.example.com/Datacenter/esxi?no_verify=1' \
981 "Windows 2003" \
982 -o local -os /var/tmp
983 where "Windows 2003" is the name of the guest (which must be shut
985 down).
986 Note that you may be asked for the vCenter password twice. This
988 happens once because libvirt needs it, and a second time because
989 virt-v2v itself connects directly to the server. Use --password-file
990 to supply a password via a file.
991 In this case the output flags are set to write the converted guest to a
993 temporary directory as this is just an example, but you can also write
994 to libvirt or any other supported target.
995 VCENTER: NON-ADMINISTRATOR ROLE
997 Instead of using the vCenter Administrator role, you can create a
998 custom non-administrator role to perform the conversion. You will
999 however need to give it a minimum set of permissions as follows:
1000 1. Create a custom role in vCenter.
1002 2. Enable (check) the following objects:
1004 Datastore:
1006 - Browse datastore
1007 - Low level file operations
1008 Sessions:
1010 - Validate session
1011 Virtual Machine:
1013 Provisioning:
1014 - Allow disk access
1015 - Allow read-only disk access
1016 - Guest Operating system management by VIX API
1017 VCENTER: FIREWALL AND PROXY SETTINGS
1019 vCenter: Ports
1020 If there is a firewall between the virt-v2v conversion server and the
1022 vCenter server, then you will need to open port 443 (https) and port
1023 5480.
1024 Port 443 is used to copy the guest disk image(s). Port 5480 is used to
1026 query vCenter for guest metadata.
1027 These port numbers are only the defaults. It is possible to
1029 reconfigure vCenter to use other port numbers. In that case you would
1030 need to specify those ports in the "vpx://" URI. See "VCENTER: URI"
1031 above.
1032 These ports only apply to virt-v2v conversions. You may have to open
1034 other ports for other vCenter functionality, for example the web user
1035 interface. VMware documents the required ports for vCenter in their
1036 online documentation.
1037 ┌────────────┐ port 443 ┌────────────┐ ┌────────────┐
1039 │ virt-v2v │────────────▶ vCenter │────────▶ ESXi │
1040 │ conversion │────────────▶ server │ │ hypervisor │
1041 │ server │ port 5480 │ │ │ ┌─────┐ │
1042 └────────────┘ └────────────┘ │ │guest│ │
1043 └───┴─────┴──┘
1044 (In the diagram above the arrows show the direction in which the TCP
1046 connection is initiated, not necessarily the direction of data
1047 transfer.)
1048 Virt-v2v itself does not connect directly to the ESXi hypervisor
1050 containing the guest. However vCenter connects to the hypervisor and
1051 forwards the information, so if you have a firewall between vCenter and
1052 its hypervisors you may need to open additional ports (consult VMware
1053 documentation).
1054 The proxy environment variables ("https_proxy", "all_proxy",
1056 "no_proxy", "HTTPS_PROXY", "ALL_PROXY" and "NO_PROXY") are ignored when
1057 doing vCenter conversions.
1058 VCENTER: SSL/TLS CERTIFICATE PROBLEMS
1060 You may see this error:
1061 CURL: Error opening file: SSL: no alternative certificate subject
1063 name matches target host name
1064 (You may need to enable debugging with ‘virt-v2v -v -x’ to see this
1066 message).
1067 This can be caused by using an IP address instead of the fully-
1069 qualified DNS domain name of the vCenter server, ie. use
1070 "vpx://vcenter.example.com/..." instead of "vpx://11.22.33.44/..."
1071 Another certificate problem can be caused by the vCenter server having
1073 a mismatching FQDN and IP address, for example if the server acquired a
1074 new IP address from DHCP. To fix this you need to change your DHCP
1075 server or network configuration so that the vCenter server always gets
1076 a stable IP address. After that log in to the vCenter server’s admin
1077 console at "https://vcenter:5480/". Under the "Admin" tab, select
1078 "Certificate regeneration enabled" and then reboot it.
1079
1081 Virt-v2v is able to import guests from VMware’s OVA (Open
1082 Virtualization Appliance) files. Only OVAs exported from VMware
1083 vSphere will work.
1084 OVA: REMOVE VMWARE TOOLS FROM WINDOWS GUESTS
1086 For Windows guests, you should remove VMware tools before conversion.
1087 Although this is not strictly necessary, and the guest will still be
1088 able to run, if you don't do this then the converted guest will
1089 complain on every boot. The tools cannot be removed after conversion
1090 because the uninstaller checks if it is running on VMware and refuses
1091 to start (which is also the reason that virt-v2v cannot remove them).
1092 This is not necessary for Linux guests, as virt-v2v is able to remove
1094 VMware tools.
1095 OVA: CREATE OVA
1097 To create an OVA in vSphere, use the "Export OVF Template" option (from
1098 the VM context menu, or from the File menu). Either "Folder of files"
1099 (OVF) or "Single file" (OVA) will work, but OVA is probably easier to
1100 deal with. OVA files are really just uncompressed tar files, so you
1101 can use commands like "tar tf VM.ova" to view their contents.
1102 Create OVA with ovftool
1104 You can also use VMware’s proprietary "ovftool":
1106 ovftool --noSSLVerify \
1108 vi://USER:PASSWORD@esxi.example.com/VM \
1109 VM.ova
1110 To connect to vCenter:
1112 ovftool --noSSLVerify \
1114 vi://USER:PASSWORD@vcenter.example.com/DATACENTER-NAME/vm/VM \
1115 VM.ova
1116 For Active Directory-aware authentication, you have to express the "@"
1118 character in the form of its ascii hex-code (%5c):
1119 vi://DOMAIN%5cUSER:PASSWORD@...
1121 OVA: IMPORTING A GUEST
1123 To import an OVA file called VM.ova, do;
1124 $ virt-v2v -i ova VM.ova -o local -os /var/tmp
1126 If you exported the guest as a "Folder of files", or if you unpacked
1128 the OVA tarball yourself, then you can point virt-v2v at the directory
1129 containing the files:
1130 $ virt-v2v -i ova /path/to/files -o local -os /var/tmp
1132
1134 Virt-v2v is able to import guests from VMware’s vmx files.
1135 This is useful in two cases:
1137 1. VMware virtual machines are stored on a separate NFS server and you
1139 are able to mount the NFS storage directly.
1140 2. You have enabled SSH access to the VMware ESXi hypervisor and there
1142 is a "/vmfs/volumes" folder containing the virtual machines.
1143 If you find a folder of files called guest.vmx, guest.vmxf, guest.nvram
1145 and one or more .vmdk disk images, then you can use this method.
1146 VMX: REMOVE VMWARE TOOLS FROM WINDOWS GUESTS
1148 For Windows guests, you should remove VMware tools before conversion.
1149 Although this is not strictly necessary, and the guest will still be
1150 able to run, if you don't do this then the converted guest will
1151 complain on every boot. The tools cannot be removed after conversion
1152 because the uninstaller checks if it is running on VMware and refuses
1153 to start (which is also the reason that virt-v2v cannot remove them).
1154 This is not necessary for Linux guests, as virt-v2v is able to remove
1156 VMware tools.
1157 VMX: GUEST MUST BE SHUT DOWN
1159 The guest must be shut down before conversion starts. If you don't
1160 shut it down, you will end up with a corrupted VM disk on the target.
1161 With other methods, virt-v2v tries to prevent concurrent access, but
1162 because the -i vmx method works directly against the storage, checking
1163 for concurrent access is not possible.
1164 VMX: ACCESS TO THE STORAGE CONTAINING THE VMX AND VMDK FILES
1166 If the vmx and vmdk files aren't available locally then you must either
1167 mount the NFS storage on the conversion server or enable passwordless
1168 SSH on the ESXi hypervisor.
1169 VMX: Passwordless SSH using ssh-agent
1171 You must also use ssh-agent, and add your ssh public key to
1173 /etc/ssh/keys-root/authorized_keys (on the ESXi hypervisor).
1174 After doing this, you should check that passwordless access works from
1176 the virt-v2v server to the ESXi hypervisor. For example:
1177 $ ssh root@esxi.example.com
1179 [ logs straight into the shell, no password is requested ]
1180 Note that password-interactive and Kerberos access are not supported.
1182 You have to set up ssh access using ssh-agent and authorized_keys.
1183 VMX: Construct the SSH URI
1185 When using the SSH input transport you must specify a remote
1187 "ssh://..." URI pointing to the VMX file. A typical URI looks like:
1188 ssh://root@esxi.example.com/vmfs/volumes/datastore1/my%20guest/my%20guest.vmx
1190 Any space must be escaped with %20 and other non-ASCII characters may
1192 also need to be URI-escaped.
1193 The username is not required if it is the same as your local username.
1195 You may optionally supply a port number after the hostname if the SSH
1197 server is not listening on the default port (22).
1198 VMX: IMPORTING A GUEST
1200 To import a vmx file from a local file or NFS, do:
1201 $ virt-v2v -i vmx guest.vmx -o local -os /var/tmp
1203 To import a vmx file over SSH, add -it ssh to select the SSH transport
1205 and supply a remote SSH URI:
1206 $ virt-v2v \
1208 -i vmx -it ssh \
1209 "ssh://root@esxi.example.com/vmfs/volumes/datastore1/guest/guest.vmx" \
1210 -o local -os /var/tmp
1211 Virt-v2v processes the vmx file and uses it to find the location of any
1213 vmdk disks.
1214
1216 You should use the OVA or VMX methods above (see "INPUT FROM VMWARE
1217 OVA" and/or "INPUT FROM VMWARE VMX") if possible, as it is much faster
1218 and requires much less disk space than the method described in this
1219 section.
1220 You can use the virt-v2v-copy-to-local(1) tool to copy the guest off
1222 the hypervisor into a local file, and then convert it.
1223 ESXi: REMOVE VMWARE TOOLS FROM WINDOWS GUESTS
1225 For Windows guests, you should remove VMware tools before conversion.
1226 Although this is not strictly necessary, and the guest will still be
1227 able to run, if you don't do this then the converted guest will
1228 complain on every boot. The tools cannot be removed after conversion
1229 because the uninstaller checks if it is running on VMware and refuses
1230 to start (which is also the reason that virt-v2v cannot remove them).
1231 This is not necessary for Linux guests, as virt-v2v is able to remove
1233 VMware tools.
1234 ESXi: URI
1236 The libvirt URI for VMware ESXi hypervisors will look something like
1237 this:
1238 esx://root@esxi.example.com?no_verify=1
1240 The "?no_verify=1" parameter disables TLS certificate checking.
1242 ESXi: TEST LIBVIRT CONNECTION TO ESXi HYPERVISOR
1244 Use the virsh(1) command to test the URI and list the remote guests
1245 available:
1246 $ virsh -c esx://root@esxi.example.com?no_verify=1 list --all
1248 Enter root's password for esxi.example.com: ***
1249 Id Name State
1250 ----------------------------------------------------
1251 - guest shut off
1252 ESXi: COPY THE GUEST TO THE LOCAL MACHINE
1254 Using the libvirt URI as the -ic option, copy one of the guests to the
1255 local machine:
1256 $ virt-v2v-copy-to-local -ic esx://root@esxi.example.com?no_verify=1 guest
1258 This creates guest.xml, guest-disk1, ...
1260 ESXi: DO THE VIRT-V2V CONVERSION
1262 Perform the conversion of the guest using virt-v2v:
1263 $ virt-v2v -i libvirtxml guest.xml -o local -os /var/tmp
1265 ESXi: CLEAN UP
1267 Remove the guest.xml and guest-disk* files.
1268
1270 Virt-v2v is able to import guests using VMware’s proprietary VDDK
1271 library (a.k.a. VixDiskLib).
1272 VDDK: PREREQUISITES
1274 1. As the VDDK library is not open source, and the license of this
1275 library does not permit redistribution or commercial use, you must
1276 obtain VDDK yourself and satisfy yourself that your usage of the
1277 library is permitted by the license.
1278 2. You must also compile nbdkit, enabling the VDDK plugin. nbdkit ≥
1280 1.1.25 is recommended, but it is usually best to compile from the
1281 git tree.
1282 · https://github.com/libguestfs/nbdkit
1284 · https://github.com/libguestfs/nbdkit/tree/master/plugins/vddk
1286 Compile nbdkit as described in the sources (see link above).
1288 You do not need to run "make install" because you can run nbdkit
1290 from its source directory. The source directory has a shell script
1291 called nbdkit which runs the locally built copy of nbdkit and its
1292 plugins. So set $PATH to point to the nbdkit top build directory
1293 (that is, the directory containing the shell script called nbdkit),
1294 eg:
1295 export PATH=/path/to/nbdkit-1.1.x:$PATH
1297 3. You must find the SSL "thumbprint" of your VMware server. How to
1299 do this is explained in nbdkit-vddk-plugin(1), also available at
1300 the link above.
1301 4. VDDK imports require a feature added in libvirt ≥ 3.7.
1303 VDDK: URI
1305 Construct the correct "vpx://" (for vCenter) or "esx://" (for ESXi)
1306 URL. It will look something like these:
1307 vpx://root@vcenter.example.com/Datacenter/esxi
1309 esx://root@esxi.example.com
1311 To verify that you have the correct URL, use the virsh(1) command to
1313 list the guests on the server:
1314 $ virsh -c 'vpx://root@vcenter.example.com/Datacenter/esxi' list --all
1316 Enter root's password for vcenter.example.com: ***
1317 Id Name State
1319 ----------------------------------------------------
1320 - Fedora 20 shut off
1321 - Windows 2003 shut off
1322 If you get an error "Peer certificate cannot be authenticated with
1324 given CA certificates" or similar, then you can either import the
1325 vCenter host’s certificate, or bypass signature verification by adding
1326 the "?no_verify=1" flag:
1327 $ virsh -c 'vpx://root@vcenter.example.com/Datacenter/esxi?no_verify=1' list --all
1329 You should also try dumping the metadata from any guest on your server,
1331 like this:
1332 $ virsh -c 'vpx://root@vcenter.example.com/Datacenter/esxi' dumpxml "Windows 2003"
1334 <domain type='vmware'>
1335 <name>Windows 2003</name>
1336 [...]
1337 <vmware:moref>vm-123</vmware:moref>
1338 </domain>
1339 If "<vmware:moref>" does not appear in the metadata, then you need to
1341 upgrade libvirt.
1342 If the above commands do not work, then virt-v2v is not going to work
1344 either. Fix your URI and/or your VMware server before continuing.
1345 VDDK: IMPORTING A GUEST
1347 The -it vddk parameter selects VDDK as the input transport for disks.
1348 To import a particular guest from vCenter server or ESXi hypervisor,
1350 use a command like the following, substituting the URI, guest name and
1351 SSL thumbprint:
1352 $ export PATH=/path/to/nbdkit-1.1.x:$PATH
1354 $ virt-v2v \
1355 -ic 'vpx://root@vcenter.example.com/Datacenter/esxi?no_verify=1' \
1356 -it vddk \
1357 -io vddk-libdir=/path/to/vmware-vix-disklib-distrib \
1358 -io vddk-thumbprint=xx:xx:xx:... \
1359 "Windows 2003" \
1360 -o local -os /var/tmp
1361 Other options that you might need to add in rare circumstances include
1363 -io vddk-config, -io vddk-cookie, -io vddk-nfchostport, -io vddk-port,
1364 -io vddk-snapshot, -io vddk-transports and -io vddk-vimapiver, which
1365 are all explained in the nbdkit-vddk-plugin(1) documentation.
1366 VDDK: DEBUGGING VDDK FAILURES
1368 The VDDK library can be operated in a verbose mode where it gives
1369 (very) verbose messages. Use ‘virt-v2v -v -x’ as usual to enable
1370 verbose messages.
1371
1373 Virt-v2v is able to import Xen guests from RHEL 5 Xen hosts.
1374 Virt-v2v uses libvirt for access to the remote Xen host, and therefore
1376 the input mode should be -i libvirt. As this is the default, you don't
1377 need to specify it on the command line.
1378 XEN: SET UP SSH-AGENT ACCESS TO XEN HOST
1380 Currently you must enable passwordless SSH access to the remote Xen
1381 host from the virt-v2v conversion server.
1382 You must also use ssh-agent, and add your ssh public key to
1384 /root/.ssh/authorized_keys (on the Xen host).
1385 After doing this, you should check that passwordless access works from
1387 the virt-v2v server to the Xen host. For example:
1388 $ ssh root@xen.example.com
1390 [ logs straight into the shell, no password is requested ]
1391 Note that password-interactive and Kerberos access are not supported.
1393 You have to set up ssh access using ssh-agent and authorized_keys.
1394 With some modern ssh implementations, legacy crypto policies required
1396 to interoperate with RHEL 5 sshd are disabled. To enable them you may
1397 need to run this command on the conversion server (ie. ssh client), but
1398 read update-crypto-policies(8) first:
1399 # update-crypto-policies LEGACY
1401 XEN: TEST LIBVIRT CONNECTION TO REMOTE XEN HOST
1403 Use the virsh(1) command to list the guests on the remote Xen host:
1404 $ virsh -c xen+ssh://root@xen.example.com list --all
1406 Id Name State
1407 ----------------------------------------------------
1408 0 Domain-0 running
1409 - rhel49-x86_64-pv shut off
1410 You should also try dumping the metadata from any guest on your server,
1412 like this:
1413 $ virsh -c xen+ssh://root@xen.example.com dumpxml rhel49-x86_64-pv
1415 <domain type='xen'>
1416 <name>rhel49-x86_64-pv</name>
1417 [...]
1418 </domain>
1419 If the above commands do not work, then virt-v2v is not going to work
1421 either. Fix your libvirt configuration or the remote server before
1422 continuing.
1423 If the guest disks are located on a host block device, then the
1425 conversion will fail. See "XEN OR SSH CONVERSIONS FROM BLOCK DEVICES"
1426 below for a workaround.
1427 XEN: IMPORTING A GUEST
1429 To import a particular guest from a Xen server, do:
1430 $ LIBGUESTFS_BACKEND=direct \
1432 virt-v2v -ic 'xen+ssh://root@xen.example.com' \
1433 rhel49-x86_64-pv \
1434 -o local -os /var/tmp
1435 where "rhel49-x86_64-pv" is the name of the guest (which must be shut
1437 down).
1438 In this case the output flags are set to write the converted guest to a
1440 temporary directory as this is just an example, but you can also write
1441 to libvirt or any other supported target.
1442 Setting the backend to "direct" is a temporary workaround until libvirt
1444 bug 1140166 is fixed.
1445 XEN OR SSH CONVERSIONS FROM BLOCK DEVICES
1447 Currently virt-v2v cannot directly access a Xen guest (or any guest
1448 located remotely over ssh) if that guest’s disks are located on host
1449 block devices.
1450 To tell if a Xen guest uses host block devices, look at the guest XML.
1452 You will see:
1453 <disk type='block' device='disk'>
1455 ...
1456 <source dev='/dev/VG/guest'/>
1457 where "type='block'", "source dev=" and "/dev/..." are all indications
1459 that the disk is located on a host block device.
1460 This happens because the qemu ssh block driver that we use to access
1462 remote disks uses the ssh sftp protocol, and this protocol cannot
1463 correctly detect the size of host block devices.
1464 The workaround is to copy the guest over to the conversion server,
1466 using the separate virt-v2v-copy-to-local(1) tool, followed by running
1467 virt-v2v. You will need sufficient space on the conversion server to
1468 store a full copy of the guest.
1469 virt-v2v-copy-to-local -ic xen+ssh://root@xen.example.com guest
1471 virt-v2v -i libvirtxml guest.xml -o local -os /var/tmp
1472 rm guest.xml guest-disk*
1473
1475 The -o libvirt option lets you upload the converted guest to a libvirt-
1476 managed host. There are several limitations:
1477 · You can only use a local libvirt connection [see below for how to
1479 workaround this].
1480 · The -os pool option must specify a directory pool, not anything
1482 more exotic such as iSCSI [but see below].
1483 · You can only upload to a KVM hypervisor.
1485 To output to a remote libvirt instance and/or a non-directory storage
1487 pool you have to use the following workaround:
1488 1. Use virt-v2v in -o local mode to convert the guest disks and
1490 metadata into a local temporary directory:
1491 virt-v2v [...] -o local -os /var/tmp
1493 This creates two (or more) files in /var/tmp called:
1495 /var/tmp/NAME.xml # the libvirt XML (metadata)
1497 /var/tmp/NAME-sda # the guest’s first disk
1498 (for "NAME" substitute the guest’s name).
1500 2. Upload the converted disk(s) into the storage pool called "POOL":
1502 size=$(stat -c%s /var/tmp/NAME-sda)
1504 virsh vol-create-as POOL NAME-sda $size --format raw
1505 virsh vol-upload --pool POOL NAME-sda /var/tmp/NAME-sda
1506 3. Edit /var/tmp/NAME.xml to change /var/tmp/NAME-sda to the pool
1508 name. In other words, locate the following bit of XML:
1509 <disk type='file' device='disk'>
1511 <driver name='qemu' type='raw' cache='none' />
1512 <source file='/var/tmp/NAME-sda' />
1513 <target dev='hda' bus='ide' />
1514 </disk>
1515 and change two things: The "type='file'" attribute must be changed
1517 to "type='volume'", and the "<source>" element must be changed to
1518 include "pool" and "volume" attributes:
1519 <disk type='volume' device='disk'>
1521 ...
1522 <source pool='POOL' volume='NAME-sda' />
1523 ...
1524 </disk>
1525 4. Define the final guest in libvirt:
1527 virsh define /var/tmp/NAME.xml
1529
1531 This new method to upload guests to oVirt or RHV directly via the REST
1532 API requires oVirt/RHV ≥ 4.2.
1533 You need to specify -o rhv-upload as well as the following extra
1535 parameters:
1536 -oc "https://ovirt-engine.example.com/ovirt-engine/api"
1538 The URL of the REST API which is usually the server name with
1539 "/ovirt-engine/api" appended, but might be different if you
1540 installed oVirt Engine on a different path.
1541 You can optionally add a username and port number to the URL. If
1543 the username is not specified then virt-v2v defaults to using
1544 "admin@internal" which is the typical superuser account for oVirt
1545 instances.
1546 -op password-file
1548 A file containing a password to be used when connecting to the
1549 oVirt engine. Note the file should contain the whole password,
1550 without any trailing newline, and for security the file should have
1551 mode 0600 so that others cannot read it.
1552 -os "ovirt-data"
1554 The storage domain.
1555 -oo rhv-cafile=ca.pem
1557 The ca.pem file (Certificate Authority), copied from
1558 /etc/pki/ovirt-engine/ca.pem on the oVirt engine.
1559 -oo rhv-cluster="CLUSTERNAME"
1561 Set the RHV Cluster Name. If not given it uses "Default".
1562 -oo rhv-direct
1564 If this option is given then virt-v2v will attempt to directly
1565 upload the disk to the oVirt node, otherwise it will proxy the
1566 upload through the oVirt engine. Direct upload requires that you
1567 have network access to the oVirt nodes. Non-direct upload is
1568 slightly slower but should work in all situations.
1569 -oo rhv-verifypeer
1571 Verify the oVirt/RHV server’s identity by checking the server‘s
1572 certificate against the Certificate Authority.
1573
1575 This section only applies to the -o rhv output mode. If you use
1576 virt-v2v from the RHV-M user interface, then behind the scenes the
1577 import is managed by VDSM using the -o vdsm output mode (which end
1578 users should not try to use directly).
1579 You have to specify -o rhv and an -os option that points to the RHV-M
1581 Export Storage Domain. You can either specify the NFS server and
1582 mountpoint, eg. "-os rhv-storage:/rhv/export", or you can mount that
1583 first and point to the directory where it is mounted, eg.
1584 "-os /tmp/mnt". Be careful not to point to the Data Storage Domain by
1585 accident as that will not work.
1586 On successful completion virt-v2v will have written the new guest to
1588 the Export Storage Domain, but it will not yet be ready to run. It
1589 must be imported into RHV using the UI before it can be used.
1590 In RHV ≥ 2.2 this is done from the Storage tab. Select the export
1592 domain the guest was written to. A pane will appear underneath the
1593 storage domain list displaying several tabs, one of which is "VM
1594 Import". The converted guest will be listed here. Select the
1595 appropriate guest an click "Import". See the RHV documentation for
1596 additional details.
1597 If you export several guests, then you can import them all at the same
1599 time through the UI.
1600 RHV: TESTING RHV CONVERSIONS
1602 If you do not have an oVirt or RHV instance to test against, then you
1603 can test conversions by creating a directory structure which looks
1604 enough like a RHV-M Export Storage Domain to trick virt-v2v:
1605 uuid=`uuidgen`
1607 mkdir /tmp/rhv
1608 mkdir /tmp/rhv/$uuid
1609 mkdir /tmp/rhv/$uuid/images
1610 mkdir /tmp/rhv/$uuid/master
1611 mkdir /tmp/rhv/$uuid/master/vms
1612 touch /tmp/rhv/$uuid/dom_md
1613 virt-v2v [...] -o rhv -os /tmp/rhv
1614
1616 To output to OpenStack Glance, use the -o glance option.
1617 This runs the glance(1) CLI program which must be installed on the
1619 virt-v2v conversion host. For authentication to work, you will need to
1620 set "OS_*" environment variables. In most cases you can do this by
1621 sourcing a file called something like keystonerc_admin.
1622 Virt-v2v adds metadata for the guest to Glance, describing such things
1624 as the guest operating system and what drivers it requires. The
1625 command "glance image-show" will display the metadata as "Property"
1626 fields such as "os_type" and "hw_disk_bus".
1627 Glance and sparseness
1629 Glance image upload doesn't appear to correctly handle sparseness. For
1630 this reason, using qcow2 will be faster and use less space on the
1631 Glance server. Use the virt-v2v -of qcow2 option.
1632 Glance and multiple disks
1634 If the guest has a single disk, then the name of the disk in Glance
1635 will be the name of the guest. You can control this using the -on
1636 option.
1637 Glance doesn't have a concept of associating multiple disks with a
1639 single guest, and Nova doesn't allow you to boot a guest from multiple
1640 Glance disks either. If the guest has multiple disks, then the first
1641 (assumed to be the system disk) will have the name of the guest, and
1642 the second and subsequent data disks will be called "guestname-disk2",
1643 "guestname-disk3" etc. It may be best to leave the system disk in
1644 Glance, and import the data disks to Cinder (see next section).
1645 Importing disks into Cinder
1647 Since most virt-v2v guests are "pets", Glance is perhaps not the best
1648 place to store them. There is no way for virt-v2v to upload directly
1649 to Cinder (https://bugzilla.redhat.com/1155229). There are two ways to
1650 upload to Cinder:
1651 1. Import the image to Glance first (ie. -o glance) and then copy it
1653 to Cinder:
1654 cinder create --image-id <GLANCE-IMAGE-UUID> <SIZE>
1656 2. Create (through some other means) a new volume / LUN in your Cinder
1658 backing store. Migrate the guest to this volume (using -o local).
1659 Then ask Cinder to take over management of the volume using:
1660 cinder manage <VOLUMEREF>
1662
1664 Network
1665 The most important resource for virt-v2v appears to be network
1666 bandwidth. Virt-v2v should be able to copy guest data at gigabit
1667 ethernet speeds or greater.
1668 Ensure that the network connections between servers (conversion server,
1670 NFS server, vCenter, Xen) are as fast and as low latency as possible.
1671 Disk space
1673 Virt-v2v places potentially large temporary files in $TMPDIR (which is
1674 /var/tmp if you don't set it). Using tmpfs is a bad idea.
1675 For each guest disk, an overlay is stored temporarily. This stores the
1677 changes made during conversion, and is used as a cache. The overlays
1678 are not particularly large - tens or low hundreds of megabytes per disk
1679 is typical. In addition to the overlay(s), input and output methods
1680 may use disk space, as outlined in the table below.
1681 -i ova
1683 This temporarily places a full copy of the uncompressed source
1684 disks in $TMPDIR.
1685 -o glance
1687 This temporarily places a full copy of the output disks in $TMPDIR.
1688 -o local
1690 -o qemu
1691 You must ensure there is sufficient space in the output directory
1692 for the converted guest.
1693 See also "Minimum free space check in the host" below.
1695 VMware vCenter resources
1697 Copying from VMware vCenter is currently quite slow, but we believe
1698 this to be an issue with VMware. Ensuring the VMware ESXi hypervisor
1699 and vCenter are running on fast hardware with plenty of memory should
1700 alleviate this.
1701 Compute power and RAM
1703 Virt-v2v is not especially compute or RAM intensive. If you are
1704 running many parallel conversions, then you may consider allocating one
1705 CPU core and 2 GB of RAM per running instance.
1706 Virt-v2v can be run in a virtual machine.
1708 Trimming
1710 Virt-v2v attempts to optimize the speed of conversion by ignoring guest
1711 filesystem data which is not used. This would include unused
1712 filesystem blocks, blocks containing zeroes, and deleted files.
1713 To do this, virt-v2v issues a non-destructive fstrim(8) operation. As
1715 this happens to an overlay placed over the guest data, it does not
1716 affect the source in any way.
1717 If this fstrim operation fails, you will see a warning, but virt-v2v
1719 will continue anyway. It may run more slowly (in some cases much more
1720 slowly), because it is copying the unused parts of the disk.
1721 Unfortunately support for fstrim is not universal, and it also depends
1723 on specific details of the filesystem, partition alignment, and backing
1724 storage. As an example, NTFS filesystems cannot be fstrimmed if they
1725 occupy a partition which is not aligned to the underlying storage.
1726 That was the default on Windows before Vista. As another example, VFAT
1727 filesystems (used by UEFI guests) cannot be trimmed at all.
1728 fstrim support in the Linux kernel is improving gradually, so over time
1730 some of these restrictions will be lifted and virt-v2v will work
1731 faster.
1732
1734 Guest network configuration
1735 Virt-v2v cannot currently reconfigure a guest’s network configuration.
1736 If the converted guest is not connected to the same subnet as the
1737 source, its network configuration may have to be updated. See also
1738 virt-customize(1).
1739 Converting a Windows guest
1741 When converting a Windows guests, the conversion process is split into
1742 two stages:
1743 1. Offline conversion.
1745 2. First boot.
1747 The guest will be bootable after the offline conversion stage, but will
1749 not yet have all necessary drivers installed to work correctly. These
1750 will be installed automatically the first time the guest boots.
1751 N.B. Take care not to interrupt the automatic driver installation
1753 process when logging in to the guest for the first time, as this may
1754 prevent the guest from subsequently booting correctly.
1755
1757 Free space in the guest
1758 Virt-v2v checks there is sufficient free space in the guest filesystem
1759 to perform the conversion. Currently it checks:
1760 Linux root filesystem or Windows "C:" drive
1762 Minimum free space: 20 MB
1763 Linux /boot
1765 Minimum free space: 50 MB
1766 This is because we need to build a new initramfs for some
1768 Enterprise Linux conversions.
1769 Any other mountable filesystem
1771 Minimum free space: 10 MB
1772 Minimum free space check in the host
1774 You must have sufficient free space in the host directory used to store
1775 temporary overlays. To find out which directory this is, use:
1776 $ df -h "`guestfish get-cachedir`"
1778 Filesystem Size Used Avail Use% Mounted on
1779 /dev/mapper/root 50G 40G 6.8G 86% /
1780 and look under the "Avail" column. Virt-v2v will refuse to do the
1782 conversion at all unless at least 1GB is available there.
1783 See also "RESOURCE REQUIREMENTS" above.
1785
1787 Nothing in virt-v2v inherently needs root access, and it will run just
1788 fine as a non-root user. However, certain external features may
1789 require either root or a special user:
1790 Mounting the Export Storage Domain
1792 When using -o rhv -os server:/esd virt-v2v has to have sufficient
1793 privileges to NFS mount the Export Storage Domain from "server".
1794 You can avoid needing root here by mounting it yourself before
1796 running virt-v2v, and passing -os /mountpoint instead, but first of
1797 all read the next section ...
1798 Writing to the Export Storage Domain as 36:36
1800 RHV-M cannot read files and directories from the Export Storage
1801 Domain unless they have UID:GID 36:36. You will see VM import
1802 problems if the UID:GID is not correct.
1803 When you run virt-v2v -o rhv as root, virt-v2v attempts to create
1805 files and directories with the correct ownership. If you run
1806 virt-v2v as non-root, it will probably still work, but you will
1807 need to manually change ownership after virt-v2v has finished.
1808 Writing to libvirt
1810 When using -o libvirt, you may need to run virt-v2v as root so that
1811 it can write to the libvirt system instance (ie. "qemu:///system")
1812 and to the default location for disk images (usually
1813 /var/lib/libvirt/images).
1814 You can avoid this by setting up libvirt connection authentication,
1816 see http://libvirt.org/auth.html. Alternatively, use -oc
1817 qemu:///session, which will write to your per-user libvirt
1818 instance.
1819 Writing to Glance
1821 This does not need root (in fact it probably won’t work), but may
1822 require either a special user and/or for you to source a script
1823 that sets authentication environment variables. Consult the Glance
1824 documentation.
1825
1827 When you export to the RHV-M Export Storage Domain, and then import
1828 that guest through the RHV-M UI, you may encounter an import failure.
1829 Diagnosing these failures is infuriatingly difficult as the UI
1830 generally hides the true reason for the failure.
1831 There are several log files of interest:
1833 /var/log/vdsm/import/
1835 In oVirt ≥ 4.1.0, VDSM preserves the virt-v2v log file for 30 days
1836 in this directory.
1837 This directory is found on the host which performed the conversion.
1839 The host can be selected in the import dialog, or can be found
1840 under the "Events" tab in oVirt administration.
1841 /var/log/vdsm/vdsm.log
1843 As above, this file is present on the host which performed the
1844 conversion. It contains detailed error messages from low-level
1845 operations executed by VDSM, and is useful if the error was not
1846 caused by virt-v2v, but by VDSM.
1847 /var/log/ovirt-engine/engine.log
1849 This log file is stored on the RHV-M server. It contains more
1850 detail for any errors caused by the oVirt GUI.
1851
1853 When using the -i libvirtxml option, you have to supply some libvirt
1854 XML. Writing this from scratch is hard, so the template below is
1855 helpful.
1856 Note this should only be used for testing and/or where you know what
1858 you're doing! If you have libvirt metadata for the guest, always use
1859 that instead.
1860 <domain type='kvm'>
1862 <name> NAME </name>
1863 <memory>1048576</memory>
1864 <vcpu>2</vcpu>
1865 <os>
1866 <type>hvm</type>
1867 <boot dev='hd'/>
1868 </os>
1869 <features>
1870 <acpi/>
1871 <apic/>
1872 <pae/>
1873 </features>
1874 <devices>
1875 <disk type='file' device='disk'>
1876 <driver name='qemu' type='raw'/>
1877 <source file='/path/to/disk/image'/>
1878 <target dev='hda' bus='ide'/>
1879 </disk>
1880 <interface type='network'>
1881 <mac address='52:54:00:01:02:03'/>
1882 <source network='default'/>
1883 <model type='rtl8139'/>
1884 </interface>
1885 </devices>
1886 </domain>
1887
1889 The --machine-readable option can be used to make the output more
1890 machine friendly, which is useful when calling virt-v2v from other
1891 programs, GUIs etc.
1892 There are two ways to use this option.
1894 Firstly use the option on its own to query the capabilities of the
1896 virt-v2v binary. Typical output looks like this:
1897 $ virt-v2v --machine-readable
1899 virt-v2v
1900 libguestfs-rewrite
1901 colours-option
1902 vdsm-compat-option
1903 input:disk
1904 [...]
1905 output:local
1906 [...]
1907 convert:linux
1908 convert:windows
1909 A list of features is printed, one per line, and the program exits with
1911 status 0.
1912 The "input:" and "output:" features refer to -i and -o (input and
1914 output mode) options supported by this binary. The "convert:" features
1915 refer to guest types that this binary knows how to convert.
1916 Secondly use the option in conjunction with other options to make the
1918 regular program output more machine friendly.
1919 At the moment this means:
1921 1. Progress bar messages can be parsed from stdout by looking for this
1923 regular expression:
1924 ^[0-9]+/[0-9]+$
1926 2. The calling program should treat messages sent to stdout (except
1928 for progress bar messages) as status messages. They can be logged
1929 and/or displayed to the user.
1930 3. The calling program should treat messages sent to stderr as error
1932 messages. In addition, virt-v2v exits with a non-zero status code
1933 if there was a fatal error.
1934 Virt-v2v ≤ 0.9.1 did not support the --machine-readable option at all.
1936 The option was added when virt-v2v was rewritten in 2014.
1937
1939 /usr/share/virtio-win
1940 (Optional)
1941 If this directory is present, then virtio drivers for Windows
1943 guests will be found from this directory and installed in the guest
1944 during conversion.
1945
1947 "TMPDIR"
1948 Location of the temporary directory used for the potentially large
1949 temporary overlay file.
1950 See the "Disk space" section above.
1952 "VIRT_TOOLS_DATA_DIR"
1954 This can point to the directory containing data files used for
1955 Windows conversion.
1956 Normally you do not need to set this. If not set, a compiled-in
1958 default will be used (something like /usr/share/virt-tools).
1959 This directory may contain the following files:
1961 rhsrvany.exe
1963 (Required when doing conversions of Windows guests)
1964 This is the RHSrvAny Windows binary, used to install a
1966 "firstboot" script in the guest during conversion of Windows
1967 guests.
1968 See also: "https://github.com/rwmjones/rhsrvany"
1970 pvvxsvc.exe
1972 This is a Windows binary shipped with SUSE VMDP, used to
1973 install a "firstboot" script in Windows guests. It is required
1974 if you intend to use the --firstboot or --firstboot-command
1975 options with Windows guests.
1976 rhev-apt.exe
1978 (Optional)
1979 The RHV Application Provisioning Tool (RHEV APT). If this file
1981 is present, then RHEV APT will be installed in the Windows
1982 guest during conversion. This tool is a guest agent which
1983 ensures that the virtio drivers remain up to date when the
1984 guest is running on Red Hat Virtualization (RHV).
1985 This file comes from Red Hat Virtualization (RHV), and is not
1987 distributed with virt-v2v.
1988 "VIRTIO_WIN"
1990 This is where virtio drivers for Windows are searched for.
1991 If unset, then we look for drivers in whichever of these paths is
1993 found first:
1994 /usr/share/virtio-win/virtio-win.iso
1996 The ISO containing virtio drivers for Windows.
1997 /usr/share/virtio-win
1999 The exploded tree of virtio drivers for Windows. This is
2000 usually incomplete, hence the ISO is preferred.
2001 ( if unset). It can be a directory or point to virtio-win.iso (CD
2003 ROM image containing drivers).
2004 See "ENABLING VIRTIO".
2006 For other environment variables, see "ENVIRONMENT VARIABLES" in
2008 guestfs(3).
2009
2011 virt-v2v-copy-to-local(1)
2012 There are some special cases where virt-v2v cannot directly access
2013 the remote hypervisor. In that case you have to use
2014 virt-v2v-copy-to-local(1) to make a local copy of the guest first,
2015 followed by running "virt-v2v -i libvirtxml" to perform the
2016 conversion.
2017 engine-image-uploader(8)
2019 Variously called "engine-image-uploader", "ovirt-image-uploader" or
2020 "rhevm-image-uploader", this tool allows you to copy a guest from
2021 one oVirt or RHV Export Storage Domain to another. It only permits
2022 importing a guest that was previously exported from another
2023 oVirt/RHV instance.
2024 import-to-ovirt.pl
2026 This script can be used to import guests that already run on KVM to
2027 oVirt or RHV. For more information, see this blog posting by the
2028 author of virt-v2v:
2029 https://rwmj.wordpress.com/2015/09/18/importing-kvm-guests-to-ovirt-or-rhev/#content
2031
2033 virt-p2v(1), virt-customize(1), virt-df(1), virt-filesystems(1),
2034 virt-sparsify(1), virt-sysprep(1), guestfs(3), guestfish(1),
2035 qemu-img(1), virt-v2v-copy-to-local(1), virt-v2v-test-harness(1),
2036 engine-image-uploader(8), import-to-ovirt.pl, nbdkit(1),
2037 nbdkit-vddk-plugin(1), http://libguestfs.org/.
2038
2040 Richard W.M. Jones http://people.redhat.com/~rjones/
2041 Matthew Booth
2043 Mike Latimer
2045 Pino Toscano
2047 Shahar Havivi
2049 Tingting Zheng
2051
2053 Copyright (C) 2009-2018 Red Hat Inc.
2054
2056 This program is free software; you can redistribute it and/or modify it
2057 under the terms of the GNU General Public License as published by the
2058 Free Software Foundation; either version 2 of the License, or (at your
2059 option) any later version.
2060 This program is distributed in the hope that it will be useful, but
2062 WITHOUT ANY WARRANTY; without even the implied warranty of
2063 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
2064 General Public License for more details.
2065 You should have received a copy of the GNU General Public License along
2067 with this program; if not, write to the Free Software Foundation, Inc.,
2068 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
2069
2071 To get a list of bugs against libguestfs, use this link:
2072 https://bugzilla.redhat.com/buglist.cgi?component=libguestfs&product=Virtualization+Tools
2073 To report a new bug against libguestfs, use this link:
2075 https://bugzilla.redhat.com/enter_bug.cgi?component=libguestfs&product=Virtualization+Tools
2076 When reporting a bug, please supply:
2078 · The version of libguestfs.
2080 · Where you got libguestfs (eg. which Linux distro, compiled from
2082 source, etc)
2083 · Describe the bug accurately and give a way to reproduce it.
2085 · Run libguestfs-test-tool(1) and paste the complete, unedited output
2087 into the bug report.
2088libguestfs-1.38.2 2018-05-15 virt-v2v(1)