1virt-v2v(1) Virtualization Support virt-v2v(1)
2
6 virt-v2v - Convert a guest to use KVM
7
9 virt-v2v [-i mode] [other -i* options]
10 [-o mode] [other -o* options]
11 [guest|filename]
12
14 Virt-v2v converts a single guest from a foreign hypervisor to run on
15 KVM. It can read Linux and Windows guests running on VMware, Xen,
16 Hyper-V and some other hypervisors, and convert them to KVM managed by
17 libvirt, OpenStack, oVirt, Red Hat Virtualisation (RHV) or several
18 other targets. It can modify the guest to make it bootable on KVM and
19 install virtio drivers so it will run quickly.
20 There is also a companion front-end called virt-p2v(1) which comes as
22 an ISO, CD or PXE image that can be booted on physical machines to
23 virtualize those machines (physical to virtual, or p2v).
24 To estimate the disk space needed before conversion, see
26 virt-v2v-inspector(1).
27 For in-place conversion, there is a separate tool called
29 virt-v2v-in-place(1).
30 Input and Output
32 You normally run virt-v2v with several -i* options controlling the
33 input mode and also several -o* options controlling the output mode.
34 In this sense, "input" refers to the source foreign hypervisor such as
35 VMware, and "output" refers to the target KVM-based management system
36 such as oVirt or OpenStack.
37 The input and output sides of virt-v2v are separate and unrelated.
39 Virt-v2v can read from any input and write to any output. Therefore
40 these sides of virt-v2v are documented separately in this manual.
41 Virt-v2v normally copies from the input to the output, called "copying
43 mode". In this case the source guest is always left unchanged. In-
44 place conversions may be done using virt-v2v-in-place(1).
45 Other virt-v2v topics
47 virt-v2v-support(1) — Supported hypervisors, virtualization management
48 systems, guests.
49 virt-v2v-input-vmware(1) — Input from VMware.
51 virt-v2v-input-xen(1) — Input from Xen.
53 virt-v2v-output-local(1) — Output to local files or local libvirt.
55 virt-v2v-output-rhv(1) — Output to oVirt or RHV.
57 virt-v2v-output-openstack(1) — Output to OpenStack.
59 virt-v2v-release-notes-1.42(1) — Release notes for 1.42 release.
61 virt-v2v-release-notes-2.0(1) — Release notes for 2.0 release.
63 virt-v2v-release-notes-2.2(1) — Release notes for 2.2 release.
65
67 Convert from VMware vCenter server to local libvirt
68 You have a VMware vCenter server called "vcenter.example.com", a
69 datacenter called "Datacenter", and an ESXi hypervisor called "esxi".
70 You want to convert a guest called "vmware_guest" to run locally under
71 libvirt.
72 virt-v2v -ic vpx://vcenter.example.com/Datacenter/esxi vmware_guest
74 In this case you will most likely have to run virt-v2v as "root", since
76 it needs to talk to the system libvirt daemon and copy the guest disks
77 to /var/lib/libvirt/images.
78 For more information see virt-v2v-input-vmware(1).
80 Convert from VMware to RHV/oVirt
82 This is the same as the previous example, except you want to send the
83 guest to a RHV Data Domain using the RHV REST API. Guest network
84 interface(s) are connected to the target network called "ovirtmgmt".
85 virt-v2v -ic vpx://vcenter.example.com/Datacenter/esxi vmware_guest \
87 -o rhv-upload -oc https://ovirt-engine.example.com/ovirt-engine/api \
88 -os ovirt-data -op /tmp/ovirt-admin-password -of raw \
89 -oo rhv-cafile=/tmp/ca.pem --bridge ovirtmgmt
90 In this case the host running virt-v2v acts as a conversion server.
92 For more information see virt-v2v-output-rhv(1).
94 Convert from ESXi hypervisor over SSH to local libvirt
96 You have an ESXi hypervisor called "esxi.example.com" with SSH access
97 enabled. You want to convert from VMFS storage on that server to a
98 local file.
99 virt-v2v \
101 -i vmx -it ssh \
102 "ssh://root@esxi.example.com/vmfs/volumes/datastore1/guest/guest.vmx" \
103 -o local -os /var/tmp
104 The guest must not be running. Virt-v2v would not need to be run as
106 root in this case.
107 For more information about converting from VMX files see
109 virt-v2v-input-vmware(1).
110 Convert disk image to OpenStack
112 Given a disk image from another hypervisor that you want to convert to
113 run on OpenStack (only KVM-based OpenStack is supported), you can run
114 virt-v2v inside an OpenStack VM (called "v2v-vm" below), and do:
115 virt-v2v -i disk disk.img -o openstack -oo server-id=v2v-vm
117 See virt-v2v-output-openstack(1).
119 Convert disk image to disk image
121 Given a disk image from another hypervisor that you want to convert to
122 run on KVM, you have two options. The simplest way is to try:
123 virt-v2v -i disk disk.img -o local -os /var/tmp
125 where virt-v2v guesses everything about the input disk.img and (in this
127 case) writes the converted result to /var/tmp.
128 A more complex method is to write some libvirt XML describing the input
130 guest (if you can get the source hypervisor to provide you with libvirt
131 XML, then so much the better). You can then do:
132 virt-v2v -i libvirtxml guest-domain.xml -o local -os /var/tmp
134 Since guest-domain.xml contains the path(s) to the guest disk image(s)
136 you do not need to specify the name of the disk image on the command
137 line.
138 To convert a local disk image and immediately boot it in local qemu,
140 do:
141 virt-v2v -i disk disk.img -o qemu -os /var/tmp -oo qemu-boot
143
145 --help
146 Display help.
147 --bandwidth bps
149 --bandwidth-file filename
150 Some input methods are able to limit the network bandwidth they
151 will use statically or dynamically. In the first variant this sets
152 the bandwidth limit statically in bits per second. Formats like
153 "10M" may be used (meaning 10 megabits per second).
154 In the second variant the bandwidth is limited dynamically from the
156 content of the file (also in bits per second, in the same formats
157 supported by the first variant). You may use both parameters
158 together, meaning: first limit to a static rate, then you can
159 create the file while virt-v2v is running to adjust the rate
160 dynamically.
161 This is only supported for:
163 • input from Xen
165 • input from VMware VMX when using the SSH transport method
167 • input from VDDK
169 • -i libvirtxml when using HTTP or HTTPS disks
171 • input from VMware vCenter server
173 The options are silently ignored for other input methods.
175 -b ...
177 --bridge ...
178 See --network below.
179 --block-driver virtio-blk
181 --block-driver virtio-scsi
182 When choosing a block driver for Windows guests, prefer
183 "virtio-blk" or "virtio-scsi". The default is "virtio-blk".
184 Note this has no effect for Linux guests at the moment. That may
186 be added in future.
187 --colors
189 --colours
190 Use ANSI colour sequences to colourize messages. This is the
191 default when the output is a tty. If the output of the program is
192 redirected to a file, ANSI colour sequences are disabled unless you
193 use this option.
194 --compressed
196 This is the same as -oo compressed.
197 --echo-keys
199 When prompting for keys and passphrases, virt-v2v normally turns
200 echoing off so you cannot see what you are typing. If you are not
201 worried about Tempest attacks and there is no one else in the room
202 you can specify this flag to see what you are typing.
203 Note this options only applies to keys and passphrases for
205 encrypted devices and partitions, not for passwords used to connect
206 to remote servers.
207 -i disk
209 Set the input method to disk.
210 In this mode you can read a virtual machine disk image with no
212 metadata. virt-v2v tries to guess the best default metadata. This
213 is usually adequate but you can get finer control (eg. of memory
214 and vCPUs) by using -i libvirtxml instead. Only guests that use a
215 single disk can be imported this way.
216 -i libvirt
218 Set the input method to libvirt. This is the default.
219 In this mode you have to specify a libvirt guest name or UUID on
221 the command line. You may also specify a libvirt connection URI
222 (see -ic).
223 See "Starting the libvirt system instance" below.
225 -i libvirtxml
227 Set the input method to libvirtxml.
228 In this mode you have to pass a libvirt XML file on the command
230 line. This file is read in order to get metadata about the source
231 guest (such as its name, amount of memory), and also to locate the
232 input disks. See "Minimal XML for -i libvirtxml option" below.
233 -i local
235 This is the same as -i disk.
236 -i ova
238 Set the input method to ova.
239 In this mode you can read a VMware ova file. Virt-v2v will read
241 the ova manifest file and check the vmdk volumes for validity
242 (checksums) as well as analyzing the ovf file, and then convert the
243 guest. See virt-v2v-input-vmware(1).
244 -i vmx
246 Set the input method to vmx.
247 In this mode you can read a VMware vmx file directly or over SSH.
249 This is useful when VMware VMs are stored on an NFS server which
250 you can mount directly, or where you have access by SSH to an ESXi
251 hypervisor. See virt-v2v-input-vmware(1).
252 -ic libvirtURI
254 Specify a libvirt connection URI to use when reading the guest.
255 This is only used when -i libvirt.
256 Only local libvirt connections, VMware vCenter connections, or RHEL
258 5 Xen remote connections can be used. Other remote libvirt
259 connections will not work in general.
260 See also virt-v2v-input-vmware(1), virt-v2v-input-xen(1).
262 -if format
264 For -i disk only, this specifies the format of the input disk
265 image. For other input methods you should specify the input format
266 in the metadata.
267 -io OPTION=VALUE
269 Set input option(s) related to the current input mode or transport.
270 To display short help on what options are available you can use:
271 virt-v2v -it vddk -io "?"
273 -io vddk-libdir=LIBDIR
275 Set the VDDK library directory. This directory should contain
276 subdirectories called include, lib64 etc., but do not include lib64
277 actually in the parameter.
278 In most cases this parameter is required when using the -it vddk
280 (VDDK) transport. See virt-v2v-input-vmware(1) for details.
281 -io vddk-thumbprint=xx:xx:xx:...
283 Set the thumbprint of the remote VMware server.
284 This parameter is required when using the -it vddk (VDDK)
286 transport. See virt-v2v-input-vmware(1) for details.
287 -io vddk-config=FILENAME
289 -io vddk-cookie=COOKIE
290 -io vddk-nfchostport=PORT
291 -io vddk-port=PORT
292 -io vddk-snapshot=SNAPSHOT-MOREF
293 -io vddk-transports=MODE:MODE:...
294 When using VDDK mode, these options are passed unmodified to the
295 nbdkit(1) VDDK plugin. Please refer to nbdkit-vddk-plugin(1). Do
296 not use these options unless you know what you are doing. These
297 are all optional.
298 -ip filename
300 Supply a file containing a password to be used when connecting to
301 the target hypervisor. If this is omitted then the input
302 hypervisor may ask for the password interactively. Note the file
303 should contain the whole password, without any trailing newline,
304 and for security the file should have mode 0600 so that others
305 cannot read it.
306 -it ssh
308 When using -i vmx, this enables the ssh transport. See
309 virt-v2v-input-vmware(1).
310 -it vddk
312 Use VMware VDDK as a transport to copy the input disks. See
313 virt-v2v-input-vmware(1). If you use this parameter then you may
314 need to use other -io vddk* options to specify how to connect
315 through VDDK.
316 --key SELECTOR
318 Specify a key for LUKS, to automatically open a LUKS device when
319 using the inspection. "ID" can be either the libguestfs device
320 name, or the UUID of the LUKS device.
321 --key "ID":key:KEY_STRING
323 Use the specified "KEY_STRING" as passphrase.
324 --key "ID":file:FILENAME
326 Read the passphrase from FILENAME.
327 --key "ID":clevis
329 Attempt passphrase-less unlocking for "ID" with Clevis, over
330 the network. Please refer to "ENCRYPTED DISKS" in guestfs(3)
331 for more information on network-bound disk encryption (NBDE).
332 Note that if any such option is present on the command line,
334 QEMU user networking will be automatically enabled for the
335 libguestfs appliance.
336 --keys-from-stdin
338 Read key or passphrase parameters from stdin. The default is to
339 try to read passphrases from the user by opening /dev/tty.
340 If there are multiple encrypted devices then you may need to supply
342 multiple keys on stdin, one per line.
343 Note --keys-from-stdin only applies to keys and passphrases for
345 encrypted devices and partitions, not for passwords used to connect
346 to remote servers.
347 --mac aa:bb:cc:dd:ee:ff:network:out
349 --mac aa:bb:cc:dd:ee:ff:bridge:out
350 Map source NIC MAC address to a network or bridge.
351 See "Networks and bridges" below.
353 --mac aa:bb:cc:dd:ee:ff:ip:ipaddr[,gw[,len[,ns,ns,...]]]
355 Force a particular interface (controlled by its MAC address) to
356 have a static IP address after boot.
357 The fields in the parameter are: "ipaddr" is the IP address. "gw"
359 is the optional gateway IP address. "len" is the subnet mask
360 length (an integer). The final parameters are zero or more
361 nameserver IP addresses.
362 This option can be supplied zero or more times.
364 You only need to use this option for certain broken guests such as
366 Windows which are unable to preserve MAC to static IP address
367 mappings automatically. You don't need to use it if Windows is
368 using DHCP. It is currently ignored for Linux guests since they do
369 not have this problem.
370 --machine-readable
372 --machine-readable=format
373 This option is used to make the output more machine friendly when
374 being parsed by other programs. See "Machine readable output"
375 below.
376 -n in:out
378 -n out
379 --network in:out
380 --network out
381 -b in:out
382 -b out
383 --bridge in:out
384 --bridge out
385 Map network (or bridge) called "in" to network (or bridge) called
386 "out". If no "in:" prefix is given, all other networks (or
387 bridges) are mapped to "out".
388 See "Networks and bridges" below.
390 -o disk
392 This is the same as -o local.
393 -o glance
395 This is a legacy option. You should probably use -o openstack
396 instead.
397 Set the output method to OpenStack Glance. In this mode the
399 converted guest is uploaded to Glance. See
400 virt-v2v-output-openstack(1).
401 -o kubevirt
403 Set the output method to kubevirt. Note the way this mode works is
404 experimental and will change in future.
405 In this mode, the converted guest is written to a local directory
407 specified by -os /dir (the directory must exist). The converted
408 guest’s disks are written to:
409 /dir/name-sda
411 /dir/name-sdb
412 [etc]
413 and guest metadata is created in the associated YAML file:
415 /dir/name.yaml
417 where "name" is the guest name.
419 -o libvirt
421 Set the output method to libvirt. This is the default.
422 In this mode, the converted guest is created as a libvirt guest.
424 You may also specify a libvirt connection URI (see -oc).
425 See "Starting the libvirt system instance" below, and
427 virt-v2v-output-local(1).
428 -o local
430 Set the output method to local.
431 In this mode, the converted guest is written to a local directory
433 specified by -os /dir (the directory must exist). The converted
434 guest’s disks are written as:
435 /dir/name-sda
437 /dir/name-sdb
438 [etc]
439 and a libvirt XML file is created containing guest metadata:
441 /dir/name.xml
443 where "name" is the guest name.
445 -o null
447 Set the output method to null.
448 The guest is converted and copied but the results are thrown away
450 and no metadata is written.
451 -o openstack
453 Set the output method to OpenStack. See
454 virt-v2v-output-openstack(1).
455 -o ovirt
457 This is the same as -o rhv.
458 -o ovirt-upload
460 This is the same as -o rhv-upload.
461 -o qemu
463 Set the output method to qemu.
464 This is similar to -o local, except that a shell script is written
466 which you can use to boot the guest in qemu. The converted disks
467 and shell script are written to the directory specified by -os.
468 When using this output mode, you can also specify the -oo qemu-boot
470 option which boots the guest under qemu immediately.
471 -o rhev
473 This is the same as -o rhv.
474 -o rhv
476 Set the output method to rhv.
477 The converted guest is written to a RHV Export Storage Domain. The
479 -os parameter must also be used to specify the location of the
480 Export Storage Domain. Note this does not actually import the
481 guest into RHV. You have to do that manually later using the UI.
482 See virt-v2v-output-rhv(1).
484 -o rhv-upload
486 Set the output method to rhv-upload.
487 The converted guest is written directly to a RHV Data Domain. This
489 is a faster method than -o rhv, but requires oVirt or RHV ≥ 4.2.
490 See virt-v2v-output-rhv(1).
492 -o vdsm
494 Set the output method to vdsm.
495 This mode is similar to -o rhv, but the full path to the data
497 domain must be given:
498 /rhv/data-center/<data-center-uuid>/<data-domain-uuid>. This mode
499 is only used when virt-v2v runs under VDSM control.
500 -oa sparse
502 -oa preallocated
503 Set the output file allocation mode. The default is "sparse".
504 -oc URI
506 Specify a connection URI to use when writing the converted guest.
507 For -o libvirt this is the libvirt URI. Only local libvirt
509 connections can be used. Remote libvirt connections will not work.
510 See virt-v2v-output-local(1) for further information.
511 -of format
513 When converting the guest, convert the disks to the given format.
514 If not specified, then the input format is used.
516 -on name
518 Rename the guest when converting it. If this option is not used
519 then the output name is the same as the input name.
520 -oo OPTION=VALUE
522 Set output option(s) related to the current output mode. To
523 display short help on what options are available you can use:
524 virt-v2v -o rhv-upload -oo "?"
526 -oo compressed
528 For outputs which support qcow2 format (-of qcow2), this writes a
529 compressed qcow2 file. It is the equivalent to the -c option of
530 qemu-img(1).
531 -oo guest-id="ID"
533 For -o openstack (virt-v2v-output-openstack(1)) only, set a guest
534 ID which is saved on each Cinder volume in the "virt_v2v_guest_id"
535 volume property.
536 -oo qemu-boot
538 When using -o qemu only, this boots the guest immediately after
539 virt-v2v finishes.
540 -oo verify-server-certificate
542 -oo verify-server-certificate="true|false"
543 For -o openstack (virt-v2v-output-openstack(1)) only, this can be
544 used to disable SSL certification validation when connecting to
545 OpenStack by specifying -oo verify-server-certificate=false.
546 -oo os-*=*
548 For -o openstack (virt-v2v-output-openstack(1)) only, set optional
549 OpenStack authentication. For example -oo os-username=NAME is
550 equivalent to "openstack --os-username=NAME".
551 -oo rhv-cafile=ca.pem
553 For -o rhv-upload (virt-v2v-output-rhv(1)) only, the ca.pem file
554 (Certificate Authority), copied from /etc/pki/ovirt-engine/ca.pem
555 on the oVirt engine.
556 -oo rhv-cluster="CLUSTERNAME"
558 For -o rhv-upload (virt-v2v-output-rhv(1)) only, set the RHV
559 Cluster Name. If not given it uses "Default".
560 -oo rhv-proxy
562 For -o rhv-upload (virt-v2v-output-rhv(1)) only, proxy the upload
563 through oVirt Engine. This is slower than uploading directly to
564 the oVirt node but may be necessary if you do not have direct
565 network access to the nodes.
566 -oo rhv-verifypeer
568 For -o rhv-upload (virt-v2v-output-rhv(1)) only, verify the
569 oVirt/RHV server’s identity by checking the server‘s certificate
570 against the Certificate Authority.
571 -oo server-id="NAME|UUID"
573 For -o openstack (virt-v2v-output-openstack(1)) only, set the name
574 of the conversion appliance where virt-v2v is running.
575 -oo vdsm-compat=0.10
577 -oo vdsm-compat=1.1
578 If -o vdsm and the output format is qcow2, then we add the qcow2
579 compat=0.10 option to the output file for compatibility with RHEL 6
580 (see https://bugzilla.redhat.com/1145582).
581 If -oo vdsm-compat=1.1 is used then modern qcow2 (compat=1.1) files
583 are generated instead.
584 Currently -oo vdsm-compat=0.10 is the default, but this will change
586 to -oo vdsm-compat=1.1 in a future version of virt-v2v (when we can
587 assume that everyone is using a modern version of qemu).
588 Note this option only affects -o vdsm output. All other output
590 modes (including -o rhv) generate modern qcow2 compat=1.1 files,
591 always.
592 If this option is available, then "vdsm-compat-option" will appear
594 in the --machine-readable output.
595 -oo vdsm-image-uuid=UUID
597 -oo vdsm-vol-uuid=UUID
598 -oo vdsm-vm-uuid=UUID
599 -oo vdsm-ovf-output=DIR
600 Normally the RHV output mode chooses random UUIDs for the target
601 guest. However VDSM needs to control the UUIDs and passes these
602 parameters when virt-v2v runs under VDSM control. The parameters
603 control:
604 • the image directory of each guest disk (-oo vdsm-image-uuid)
606 (this option is passed once for each guest disk)
607 • UUIDs for each guest disk (-oo vdsm-vol-uuid) (this option is
609 passed once for each guest disk)
610 • the OVF file name (-oo vdsm-vm-uuid).
612 • the OVF output directory (default current directory) (-oo vdsm-
614 ovf-output).
615 The format of UUIDs is: "12345678-1234-1234-1234-123456789abc"
617 (each hex digit can be "0-9" or "a-f"), conforming to OSF DCE 1.1.
618 These options can only be used with -o vdsm.
620 -oo vdsm-ovf-flavour=flavour
622 This option controls the format of the OVF generated at the end of
623 conversion. Currently there are two possible flavours:
624 rhvexp
626 The OVF format used in RHV export storage domain.
627 ovirt
629 The OVF format understood by oVirt REST API.
630 For backward compatibility the default is rhvexp, but this may
632 change in the future.
633 -op file
635 Supply a file containing a password to be used when connecting to
636 the target hypervisor. Note the file should contain the whole
637 password, without any trailing newline, and for security the file
638 should have mode 0600 so that others cannot read it.
639 -os storage
641 The location of the storage for the converted guest.
642 For -o libvirt, this is a libvirt directory pool (see
644 "virsh pool-list") or pool UUID.
645 For -o local and -o qemu, this is a directory name. The directory
647 must exist.
648 For -o rhv-upload, this is the name of the destination Storage
650 Domain.
651 For -o openstack, this is the optional Cinder volume type.
653 For -o rhv, this can be an NFS path of the Export Storage Domain of
655 the form "<host>:<path>", eg:
656 rhv-storage.example.com:/rhv/export
658 The NFS export must be mountable and writable by the user and host
660 running virt-v2v, since the virt-v2v program has to actually mount
661 it when it runs. So you probably have to run virt-v2v as "root".
662 Or: You can mount the Export Storage Domain yourself, and point -os
664 to the mountpoint. Note that virt-v2v will still need to write to
665 this remote directory, so virt-v2v will still need to run as
666 "root".
667 You will get an error if virt-v2v is unable to mount/write to the
669 Export Storage Domain.
670 --print-source
672 Print information about the source guest and stop. This option is
673 useful when you are setting up network and bridge maps. See
674 "Networks and bridges".
675 --qemu-boot
677 This is the same as -oo qemu-boot.
678 -q
680 --quiet
681 This disables progress bars and other unnecessary output.
682 --root ask
684 --root single
685 --root first
686 --root /dev/sdX
687 --root /dev/VG/LV
688 Choose the root filesystem to be converted.
689 In the case where the virtual machine is dual-boot or multi-boot,
691 or where the VM has other filesystems that look like operating
692 systems, this option can be used to select the root filesystem
693 (a.k.a. "C:" drive or /) of the operating system that is to be
694 converted. The Windows Recovery Console, certain attached DVD
695 drives, and bugs in libguestfs inspection heuristics, can make a
696 guest look like a multi-boot operating system.
697 The default in virt-v2v ≤ 0.7.1 was --root single, which causes
699 virt-v2v to die if a multi-boot operating system is found.
700 Since virt-v2v ≥ 0.7.2 the default is now --root ask: If the VM is
702 found to be multi-boot, then virt-v2v will stop and list the
703 possible root filesystems and ask the user which to use. This
704 requires that virt-v2v is run interactively.
705 --root first means to choose the first root device in the case of a
707 multi-boot operating system. Since this is a heuristic, it may
708 sometimes choose the wrong one.
709 You can also name a specific root device, eg. --root /dev/sda2
711 would mean to use the second partition on the first hard drive. If
712 the named root device does not exist or was not detected as a root
713 device, then virt-v2v will fail.
714 Note that there is a bug in grub which prevents it from
716 successfully booting a multiboot system if virtio is enabled. Grub
717 is only able to boot an operating system from the first virtio
718 disk. Specifically, /boot must be on the first virtio disk, and it
719 cannot chainload an OS which is not in the first virtio disk.
720 -v
722 --verbose
723 Enable verbose messages for debugging.
724 -V
726 --version
727 Display version number and exit.
728 --wrap
730 Wrap error, warning, and informative messages. This is the default
731 when the output is a tty. If the output of the program is
732 redirected to a file, wrapping is disabled unless you use this
733 option.
734 -x Enable tracing of libguestfs API calls.
736
738 Xen paravirtualized guests
739 Older versions of virt-v2v could turn a Xen paravirtualized (PV) guest
740 into a KVM guest by installing a new kernel. This version of virt-v2v
741 does not attempt to install any new kernels. Instead it will give you
742 an error if there are only Xen PV kernels available.
743 Therefore before conversion you should check that a regular kernel is
745 installed. For some older Linux distributions, this means installing a
746 kernel from the table below:
747 RHEL 3 (Does not apply, as there was no Xen PV kernel)
749 RHEL 4 i686 with > 10GB of RAM: install 'kernel-hugemem'
751 i686 SMP: install 'kernel-smp'
752 other i686: install 'kernel'
753 x86-64 SMP with > 8 CPUs: install 'kernel-largesmp'
754 x86-64 SMP: install 'kernel-smp'
755 other x86-64: install 'kernel'
756 RHEL 5 i686: install 'kernel-PAE'
758 x86-64: install 'kernel'
759 SLES 10 i586 with > 10GB of RAM: install 'kernel-bigsmp'
761 i586 SMP: install 'kernel-smp'
762 other i586: install 'kernel-default'
763 x86-64 SMP: install 'kernel-smp'
764 other x86-64: install 'kernel-default'
765 SLES 11+ i586: install 'kernel-pae'
767 x86-64: install 'kernel-default'
768 Windows (Does not apply, as there is no Xen PV Windows kernel)
770 Enabling virtio
772 "Virtio" is the name for a set of drivers which make disk (block
773 device), network and other guest operations work much faster on KVM.
774 Older versions of virt-v2v could install these drivers for certain
776 Linux guests. This version of virt-v2v does not attempt to install new
777 Linux kernels or drivers, but will warn you if they are not installed
778 already.
779 In order to enable virtio, and hence improve performance of the guest
781 after conversion, you should ensure that the minimum versions of
782 packages are installed before conversion, by consulting the table
783 below.
784 RHEL 3 No virtio drivers are available
786 RHEL 4 kernel >= 2.5.9-89.EL
788 lvm2 >= 2.02.42-5.el4
789 device-mapper >= 1.02.28-2.el4
790 selinux-policy-targeted >= 1.17.30-2.152.el4
791 policycoreutils >= 1.18.1-4.13
792 RHEL 5 kernel >= 2.6.18-128.el5
794 lvm2 >= 2.02.40-6.el5
795 selinux-policy-targeted >= 2.4.6-203.el5
796 RHEL 6+ All versions support virtio
798 Fedora All versions support virtio
800 SLES 11+ All versions support virtio
802 SLES 10 kernel >= 2.6.16.60-0.85.1
804 OpenSUSE 11+ All versions support virtio
806 OpenSUSE 10 kernel >= 2.6.25.5-1.1
808 Debian 6+ All versions support virtio
810 Ubuntu 10.04+ All versions support virtio
812 Windows Drivers are installed from the ISO or directory pointed
814 to by the "VIRTIO_WIN" environment variable if present.
815 If the "VIRTIO_WIN" environment variable is absent
816 (which is the recommended setting), then libosinfo is
817 consulted first, for driver files that are locally
818 available on the conversion host.
819 RHEL 4: SELinux relabel appears to hang forever
821 In RHEL ≤ 4.7 there was a bug which causes SELinux relabelling to
822 appear to hang forever at:
823 *** Warning -- SELinux relabel is required. ***
825 *** Disabling security enforcement. ***
826 *** Relabeling could take a very long time, ***
827 *** depending on file system size. ***
828 In reality it is waiting for you to press a key (but there is no visual
830 indication of this). You can either hit the "[Return]" key, at which
831 point the guest will finish relabelling and reboot, or you can install
832 policycoreutils ≥ 1.18.1-4.13 before starting the v2v conversion. See
833 also https://bugzilla.redhat.com/show_bug.cgi?id=244636
834 Debian and Ubuntu
836 "warning: could not determine a way to update the configuration of
837 Grub2"
838 Currently, virt-v2v has no way to set the default kernel in Debian and
840 Ubuntu guests using GRUB 2 as bootloader. This means that virt-v2v
841 will not change the default kernel used for booting, even in case it is
842 not the best kernel available on the guest. A recommended procedure
843 is, before using virt-v2v, to check that the boot kernel is the best
844 kernel available in the guest (for example by making sure the guest is
845 up-to-date).
846 "vsyscall attempted with vsyscall=none"
848 When run on a recent Debian host virt-v2v may fail to convert guests
850 which were created before 2013. In the debugging output you will see a
851 crash message similar to:
852 vsyscall attempted with vsyscall=none ip:...
854 segfault at ...
855 This is caused because Debian removed support for running old binaries
857 which used the legacy vsyscall page to call into the kernel.
858 You can work around this problem by running this command before running
860 virt-v2v:
861 export LIBGUESTFS_APPEND="vsyscall=emulate"
863 For more information, see https://bugzilla.redhat.com/1592061
865 Windows
867 System disk on a Dynamic Disk is not supported
868 If the Windows system disk (the drive containing "\windows") is located
870 on a Dynamic Disk then it cannot be converted. Data disks — that is,
871 disks which are part of the guest but do not contain parts of the
872 Windows operating system — may be Dynamic Disks.
873 See https://bugzilla.redhat.com/2140548.
875 Windows ≥ 8 Fast Startup is incompatible with virt-v2v
877 Guests which use the Windows ≥ 8 "Fast Startup" feature (or guests
879 which are hibernated) cannot be converted with virt-v2v. You will see
880 an error:
881 virt-v2v: error: unable to mount the disk image for writing. This has
883 probably happened because Windows Hibernation or Fast Restart is being
884 used in this guest. You have to disable this (in the guest) in order
885 to use virt-v2v.
886 As the message says, you need to boot the guest and disable the "Fast
888 Startup" feature (Control Panel → Power Options → Choose what the power
889 buttons do → Change settings that are currently unavailable → Turn on
890 fast startup), and shut down the guest, and then you will be able to
891 convert it.
892 For more information, see: "WINDOWS HIBERNATION AND WINDOWS 8 FAST
894 STARTUP" in guestfs(3).
895 Boot failure: 0x0000007B
897 This boot failure is caused by Windows being unable to find or load the
899 right disk driver (eg. viostor.sys). If you experience this error,
900 here are some things to check:
901 • First ensure that the guest boots on the source hypervisor before
903 conversion.
904 • Check you have the Windows virtio drivers available in
906 /usr/share/virtio-win, and that virt-v2v did not print any warning
907 about not being able to install virtio drivers.
908 On Red Hat Enterprise Linux 7, you will need to install the signed
910 drivers available in the "virtio-win" package. If you do not have
911 access to the signed drivers, then you will probably need to
912 disable driver signing in the boot menus.
913 • Check that you are presenting a virtio-blk interface (not virtio-
915 scsi and not ide) to the guest. On the qemu/KVM command line you
916 should see something similar to this:
917 ... -drive file=windows-sda,if=virtio ...
919 In libvirt XML, you should see:
921 <target dev='vda' bus='virtio'/>
923 • Check that Windows Group Policy does not prevent the driver from
925 being installed or used. Try deleting Windows Group Policy before
926 conversion.
927 • Check there is no anti-virus or other software which implements
929 Group Policy-like prohibitions on installing or using new drivers.
930 • Enable boot debugging and check the viostor.sys driver is being
932 loaded.
933 OpenStack and Windows reactivation
935 OpenStack does not offer stable device / PCI addresses to guests.
937 Every time it creates or starts a guest, it regenerates the libvirt XML
938 for that guest from scratch. The libvirt XML will have no <address>
939 fields. Libvirt will then assign addresses to devices, in a
940 predictable manner. Addresses may change if any of the following are
941 true:
942 • A new disk or network device has been added or removed from the
944 guest.
945 • The version of OpenStack or (possibly) libvirt has changed.
947 Because Windows does not like "hardware" changes of this kind, it may
949 trigger Windows reactivation.
950 This can also prevent booting with a 7B error [see previous section] if
952 the guest has group policy containing "Device Installation
953 Restrictions".
954 Support for SHA-2 certificates in Windows 7 and Windows Server 2008 R2
956 Later versions of the Windows virtio drivers are signed using SHA-2
958 certificates (instead of SHA-1). The original shipping Windows 7 and
959 Windows Server 2008 R2 did not understand SHA-2 certificates and so the
960 Windows virtio drivers will not install properly.
961 To fix this you must apply SHA-2 Code Signing Support from:
963 https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2015/3033929
964 before converting the guest.
965 For further information see:
967 https://bugzilla.redhat.com/show_bug.cgi?id=1624878
968 Networks and bridges
970 Guests are usually connected to one or more networks, and when
971 converted to the target hypervisor you usually want to reconnect those
972 networks at the destination. The options --network, --bridge and --mac
973 allow you to do that.
974 If you are unsure of what networks and bridges are in use on the source
976 hypervisor, then you can examine the source metadata (libvirt XML,
977 vCenter information, etc.). Or you can run virt-v2v with the
978 --print-source option which causes virt-v2v to print out the
979 information it has about the guest on the source and then exit.
980 In the --print-source output you will see a section showing the guest’s
982 Network Interface Cards (NICs):
983 $ virt-v2v [-i ...] --print-source name
985 [...]
986 NICs:
987 Network "default" mac: 52:54:00:d0:cf:0e
988 Bridges are special classes of network devices which are attached to a
990 named external network on the source hypervisor, for example:
991 $ virt-v2v [-i ...] --print-source name
993 [...]
994 NICs:
995 Bridge "br0"
996 To map a specific source bridge to a target network, for example "br0"
998 on the source to "ovirtmgmt" on the target, use:
999 virt-v2v [...] --bridge br0:ovirtmgmt
1001 To map every bridge to a target network, use:
1003 virt-v2v [...] --bridge ovirtmgmt
1005 Fine-grained mapping of guest NICs
1007 The --mac option gives you more control over the mapping, letting you
1009 map single NICs to either networks or bridges on the target. For
1010 example a source guest with two NICs could map them individually to two
1011 networks called "mgmt" and "clientdata" like this:
1012 $ virt-v2v [...] \
1014 --mac 52:54:00:d0:cf:0e:network:mgmt \
1015 --mac 52:54:00:d0:cf:0f:network:clientdata
1016 Note that virt-v2v does not have the ability to change a guest’s MAC
1018 address. The MAC address is part of the guest metadata and must remain
1019 the same on source and target hypervisors. Most guests will use the
1020 MAC address to set up persistent associations between NICs and internal
1021 names (like "eth0"), with firewall settings, or even for other purposes
1022 like software licensing.
1023 Resource requirements
1025 Network
1026 The most important resource for virt-v2v appears to be network
1028 bandwidth. Virt-v2v should be able to copy guest data at gigabit
1029 ethernet speeds or greater.
1030 Ensure that the network connections between servers (conversion server,
1032 NFS server, vCenter, Xen) are as fast and as low latency as possible.
1033 Disk space
1035 Virt-v2v places potentially large temporary files in $VIRT_V2V_TMPDIR
1037 (usually /var/tmp, see also "ENVIRONMENT VARIBLES" below). Using tmpfs
1038 is a bad idea.
1039 For each guest disk, an overlay is stored temporarily. This stores the
1041 changes made during conversion, and is used as a cache. The overlays
1042 are not particularly large - tens or low hundreds of megabytes per disk
1043 is typical. In addition to the overlay(s), input and output methods
1044 may use disk space, as outlined in the table below.
1045 -i ova
1047 This temporarily places a full copy of the uncompressed source
1048 disks in $VIRT_V2V_TMPDIR (or /var/tmp).
1049 -o glance
1051 This temporarily places a full copy of the output disks in
1052 $VIRT_V2V_TMPDIR (or /var/tmp).
1053 -o local
1055 -o qemu
1056 You must ensure there is sufficient space in the output directory
1057 for the converted guest.
1058 See also "Minimum free space check in the host" below.
1060 VMware vCenter resources
1062 Copying from VMware vCenter is currently quite slow, but we believe
1064 this to be an issue with VMware. Ensuring the VMware ESXi hypervisor
1065 and vCenter are running on fast hardware with plenty of memory should
1066 alleviate this.
1067 Compute power and RAM
1069 Virt-v2v is not especially compute or RAM intensive. If you are
1071 running many parallel conversions, then you may consider allocating one
1072 CPU core and 2 GB of RAM per running instance.
1073 Virt-v2v can be run in a virtual machine.
1075 Trimming
1077 Virt-v2v attempts to optimize the speed of conversion by ignoring guest
1079 filesystem data which is not used. This would include unused
1080 filesystem blocks, blocks containing zeroes, and deleted files.
1081 To do this, virt-v2v issues a non-destructive fstrim(8) operation. As
1083 this happens to an overlay placed over the guest data, it does not
1084 affect the source in any way.
1085 If this fstrim operation fails, you will see a warning, but virt-v2v
1087 will continue anyway. It may run more slowly (in some cases much more
1088 slowly), because it is copying the unused parts of the disk.
1089 Unfortunately support for fstrim is not universal, and it also depends
1091 on specific details of the filesystem, partition alignment, and backing
1092 storage. As an example, NTFS filesystems cannot be fstrimmed if they
1093 occupy a partition which is not aligned to the underlying storage.
1094 That was the default on Windows before Vista. As another example, VFAT
1095 filesystems (used by UEFI guests) cannot be trimmed at all.
1096 fstrim support in the Linux kernel is improving gradually, so over time
1098 some of these restrictions will be lifted and virt-v2v will work
1099 faster.
1100 Post-conversion tasks
1102 Guest network configuration
1103 Virt-v2v cannot currently reconfigure a guest’s network configuration.
1105 If the converted guest is not connected to the same subnet as the
1106 source, its network configuration may have to be updated. See also
1107 virt-customize(1).
1108 Converting a Windows guest
1110 When converting a Windows guests, the conversion process is split into
1112 two stages:
1113 1. Offline conversion.
1115 2. First boot.
1117 The guest will be bootable after the offline conversion stage, but will
1119 not yet have all necessary drivers installed to work correctly. These
1120 will be installed automatically the first time the guest boots.
1121 N.B. Take care not to interrupt the automatic driver installation
1123 process when logging in to the guest for the first time, as this may
1124 prevent the guest from subsequently booting correctly.
1125 Free space for conversion
1127 Free space in the guest
1128 Virt-v2v checks there is sufficient free space in the guest filesystem
1130 to perform the conversion. Currently it checks:
1131 Linux root filesystem
1133 Minimum free space: 100 MB
1134 Linux /boot
1136 Minimum free space: 50 MB
1137 This is because we need to build a new initramfs for some
1139 Enterprise Linux conversions.
1140 Windows "C:" drive
1142 Minimum free space: 100 MB
1143 We may have to copy in many virtio drivers and guest agents.
1145 Any other mountable filesystem
1147 Minimum free space: 10 MB
1148 In addition to the actual free space, each filesystem is required to
1150 have at least 100 available inodes.
1151 Minimum free space check in the host
1153 You must have sufficient free space in the host directory used to store
1155 large temporary overlays. To find out which directory this is, use:
1156 $ df -h "`guestfish get-cachedir`"
1158 Filesystem Size Used Avail Use% Mounted on
1159 /dev/mapper/root 50G 40G 6.8G 86% /
1160 and look under the "Avail" column. Virt-v2v will refuse to do the
1162 conversion at all unless at least 1GB is available there. You can
1163 change the directory that virt-v2v uses by setting $VIRT_V2V_TMPDIR.
1164 See also "Resource requirements" above and "ENVIRONMENT VARIABLES"
1166 below.
1167 Running virt-v2v as root or non-root
1169 Nothing in virt-v2v inherently needs root access, and it will run just
1170 fine as a non-root user. However, certain external features may
1171 require either root or a special user:
1172 Mounting the Export Storage Domain
1174 When using -o rhv -os server:/esd virt-v2v has to have sufficient
1175 privileges to NFS mount the Export Storage Domain from "server".
1176 You can avoid needing root here by mounting it yourself before
1178 running virt-v2v, and passing -os /mountpoint instead, but first of
1179 all read the next section ...
1180 Writing to the Export Storage Domain as 36:36
1182 RHV-M cannot read files and directories from the Export Storage
1183 Domain unless they have UID:GID 36:36. You will see VM import
1184 problems if the UID:GID is not correct.
1185 When you run virt-v2v -o rhv as root, virt-v2v attempts to create
1187 files and directories with the correct ownership. If you run
1188 virt-v2v as non-root, it will probably still work, but you will
1189 need to manually change ownership after virt-v2v has finished.
1190 Writing to libvirt
1192 When using -o libvirt, you may need to run virt-v2v as root so that
1193 it can write to the libvirt system instance (ie. "qemu:///system")
1194 and to the default location for disk images (usually
1195 /var/lib/libvirt/images).
1196 You can avoid this by setting up libvirt connection authentication,
1198 see http://libvirt.org/auth.html. Alternatively, use -oc
1199 qemu:///session, which will write to your per-user libvirt
1200 instance.
1201 See also "Starting the libvirt system instance".
1203 Writing to Openstack
1205 Because of how Cinder volumes are presented as /dev block devices,
1206 using -o openstack normally requires that virt-v2v is run as root.
1207 Writing to Glance
1209 This does not need root (in fact it probably won’t work), but may
1210 require either a special user and/or for you to source a script
1211 that sets authentication environment variables. Consult the Glance
1212 documentation.
1213 Writing to block devices
1215 This normally requires root. See the next section.
1216 Writing to block devices
1218 Some output modes write to local files. In general these modes also
1219 let you write to block devices, but before you run virt-v2v you may
1220 have to arrange for symbolic links to the desired block devices in the
1221 output directory.
1222 For example if using -o local -os /dir then virt-v2v would normally
1224 create files called:
1225 /dir/name-sda # first disk
1227 /dir/name-sdb # second disk
1228 ...
1229 /dir/name.xml # metadata
1230 If you wish the disks to be written to block devices then you would
1232 need to create /dir/name-sda (etc) as symlinks to the block devices:
1233 # lvcreate -L 10G -n VolumeForDiskA VG
1235 # lvcreate -L 6G -n VolumeForDiskB VG
1236 # ln -sf /dev/VG/VolumeForDiskA /dir/name-sda
1237 # ln -sf /dev/VG/VolumeForDiskB /dir/name-sdb
1238 Note that you must precreate the correct number of block devices of the
1240 correct size. Typically -of raw has to be used too, but other formats
1241 such as qcow2 can be useful occasionally so virt-v2v does not force you
1242 to use raw on block devices.
1243 Minimal XML for -i libvirtxml option
1245 When using the -i libvirtxml option, you have to supply some libvirt
1246 XML. Writing this from scratch is hard, so the template below is
1247 helpful.
1248 Note this should only be used for testing and/or where you know what
1250 you're doing! If you have libvirt metadata for the guest, always use
1251 that instead.
1252 <domain type='kvm'>
1254 <name> NAME </name>
1255 <memory>1048576</memory>
1256 <vcpu>2</vcpu>
1257 <os>
1258 <type>hvm</type>
1259 <boot dev='hd'/>
1260 </os>
1261 <features>
1262 <acpi/>
1263 <apic/>
1264 <pae/>
1265 </features>
1266 <devices>
1267 <disk type='file' device='disk'>
1268 <driver name='qemu' type='raw'/>
1269 <source file='/path/to/disk/image'/>
1270 <target dev='hda' bus='ide'/>
1271 </disk>
1272 <interface type='network'>
1273 <mac address='52:54:00:01:02:03'/>
1274 <source network='default'/>
1275 <model type='rtl8139'/>
1276 </interface>
1277 </devices>
1278 </domain>
1279 Machine readable output
1281 The --machine-readable option can be used to make the output more
1282 machine friendly, which is useful when calling virt-v2v from other
1283 programs, GUIs etc.
1284 There are two ways to use this option.
1286 Firstly use the option on its own to query the capabilities of the
1288 virt-v2v binary. Typical output looks like this:
1289 $ virt-v2v --machine-readable
1291 virt-v2v
1292 libguestfs-rewrite
1293 colours-option
1294 vdsm-compat-option
1295 input:disk
1296 [...]
1297 output:local
1298 [...]
1299 convert:linux
1300 convert:windows
1301 A list of features is printed, one per line, and the program exits with
1303 status 0.
1304 The "input:" and "output:" features refer to -i and -o (input and
1306 output mode) options supported by this binary. The "convert:" features
1307 refer to guest types that this binary knows how to convert.
1308 Secondly use the option in conjunction with other options to make the
1310 regular program output more machine friendly.
1311 At the moment this means:
1313 1. Progress bar messages can be parsed from stdout by looking for this
1315 regular expression:
1316 ^[0-9]+/[0-9]+$
1318 2. The calling program should treat messages sent to stdout (except
1320 for progress bar messages) as status messages. They can be logged
1321 and/or displayed to the user.
1322 3. The calling program should treat messages sent to stderr as error
1324 messages. In addition, virt-v2v exits with a non-zero status code
1325 if there was a fatal error.
1326 Virt-v2v ≤ 0.9.1 did not support the --machine-readable option at all.
1328 The option was added when virt-v2v was rewritten in 2014.
1329 It is possible to specify a format string for controlling the output;
1331 see "ADVANCED MACHINE READABLE OUTPUT" in guestfs(3).
1332 Starting the libvirt system instance
1334 Failed to connect socket to '/var/run/libvirt/virtqemud-sock': No such file or directory
1335 Failed to connect socket to '/var/run/libvirt/virtqemud-sock-ro': Connection refused
1336 If you have just installed libvirt and virt-v2v, then you may see the
1338 errors above. This is caused by libvirt daemons that provide various
1339 services not running straight after installation. (This may depend on
1340 your distribution and vendor presets).
1341 To fix this on systemd-based distributions, do:
1343 systemctl isolate multi-user.target
1345 See also https://bugzilla.redhat.com/2182024.
1347
1349 /usr/share/virtio-win
1350 (Optional)
1351 If this directory is present, then virtio drivers for Windows
1353 guests will be found from this directory and installed in the guest
1354 during conversion.
1355
1357 "VIRT_V2V_TMPDIR"
1358 "LIBGUESTFS_CACHEDIR"
1359 Location of the temporary directory used for the potentially large
1360 temporary overlay file. If neither environment variable is set
1361 then /var/tmp is used.
1362 To reliably ensure large temporary files are cleaned up (for
1364 example in case virt-v2v crashes) you should create a randomly
1365 named directory under /var/tmp, set "VIRT_V2V_TMPDIR" to point to
1366 this directory, then when virt-v2v exits remove the directory.
1367 See the "Disk space" section above.
1369 "VIRT_TOOLS_DATA_DIR"
1371 This can point to the directory containing data files used for
1372 Windows conversion.
1373 Normally you do not need to set this. If not set, a compiled-in
1375 default will be used (something like /usr/share/virt-tools).
1376 This directory may contain the following files:
1378 rhsrvany.exe
1380 (Required when doing conversions of Windows guests)
1381 This is the RHSrvAny Windows binary, used to install a
1383 "firstboot" script in the guest during conversion of Windows
1384 guests.
1385 See also: "https://github.com/rwmjones/rhsrvany"
1387 pnp_wait.exe
1389 (Recommended when doing conversions of Windows guests)
1390 This tool waits for newly installed Windows devices to become
1392 available before trying to configure them, for example to set
1393 network configuration. It is part of the RHSrvAny project.
1394 pvvxsvc.exe
1396 This is a Windows binary shipped with SUSE VMDP, used to
1397 install a "firstboot" script in Windows guests. It is an
1398 alternative to RHSrvAny.
1399 "VIRTIO_WIN"
1401 This is an override for where virtio drivers for Windows are
1402 searched for. It can be a directory or point to virtio-win.iso (CD
1403 ROM image containing drivers).
1404 If unset, then we look for drivers via whichever of these methods
1406 succeeds first:
1407 "osinfo-db"
1409 Load osinfo data from the default paths, and attempt to find
1410 drivers via libosinfo lookup. This is the preferred method.
1411 /usr/share/virtio-win/virtio-win.iso
1413 The ISO containing virtio drivers for Windows.
1414 /usr/share/virtio-win
1416 The exploded tree of virtio drivers for Windows. This is
1417 usually incomplete, hence the least preferred method.
1418 See "Enabling virtio".
1420 For other environment variables, see "ENVIRONMENT VARIABLES" in
1422 guestfs(3).
1423
1425 engine-image-uploader(8)
1426 Variously called "engine-image-uploader", "ovirt-image-uploader" or
1427 "rhevm-image-uploader", this tool allows you to copy a guest from
1428 one oVirt or RHV Export Storage Domain to another. It only permits
1429 importing a guest that was previously exported from another
1430 oVirt/RHV instance.
1431 import-to-ovirt.pl
1433 This script can be used to import guests that already run on KVM to
1434 oVirt or RHV. For more information, see this blog posting by the
1435 author of virt-v2v:
1436 https://rwmj.wordpress.com/2015/09/18/importing-kvm-guests-to-ovirt-or-rhev/#content
1438
1440 virt-p2v(1), virt-v2v-inspector(1), virt-v2v-in-place(1),
1441 virt-customize(1), virt-df(1), virt-filesystems(1), virt-sparsify(1),
1442 virt-sysprep(1), guestfs(3), guestfish(1), qemu-img(1),
1443 engine-image-uploader(8), import-to-ovirt.pl, nbdkit(1),
1444 nbdkit-vddk-plugin(1), http://libguestfs.org/.
1445
1447 Matthew Booth
1448 Cédric Bosdonnat
1450 Laszlo Ersek
1452 Tomáš Golembiovský
1454 Shahar Havivi
1456 Richard W.M. Jones
1458 Roman Kagan
1460 Mike Latimer
1462 Nir Soffer
1464 Pino Toscano
1466 Xiaodai Wang
1468 Ming Xie
1470 Tingting Zheng
1472
1474 Copyright (C) 2009-2022 Red Hat Inc.
1475
1477 This program is free software; you can redistribute it and/or modify it
1478 under the terms of the GNU General Public License as published by the
1479 Free Software Foundation; either version 2 of the License, or (at your
1480 option) any later version.
1481 This program is distributed in the hope that it will be useful, but
1483 WITHOUT ANY WARRANTY; without even the implied warranty of
1484 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
1485 General Public License for more details.
1486 You should have received a copy of the GNU General Public License along
1488 with this program; if not, write to the Free Software Foundation, Inc.,
1489 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
1490
1492 To get a list of bugs against libguestfs, use this link:
1493 https://bugzilla.redhat.com/buglist.cgi?component=libguestfs&product=Virtualization+Tools
1494 To report a new bug against libguestfs, use this link:
1496 https://bugzilla.redhat.com/enter_bug.cgi?component=libguestfs&product=Virtualization+Tools
1497 When reporting a bug, please supply:
1499 • The version of libguestfs.
1501 • Where you got libguestfs (eg. which Linux distro, compiled from
1503 source, etc)
1504 • Describe the bug accurately and give a way to reproduce it.
1506 • Run libguestfs-test-tool(1) and paste the complete, unedited output
1508 into the bug report.
1509virt-v2v-2.3.6 2023-11-02 virt-v2v(1)