-
Notifications
You must be signed in to change notification settings - Fork 32
/
virt-v2v.pod
1674 lines (1089 loc) · 48.8 KB
/
virt-v2v.pod
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
=head1 NAME
virt-v2v - Convert a guest to use KVM
=head1 SYNOPSIS
virt-v2v [-i mode] [other -i* options]
[-o mode] [other -o* options]
[guest|filename]
=head1 DESCRIPTION
Virt-v2v converts a single guest from a foreign hypervisor to run on
KVM. It can read Linux and Windows guests running on VMware, Xen,
Hyper-V and some other hypervisors, and convert them to KVM managed by
libvirt, OpenStack, oVirt, Red Hat Virtualisation (RHV) or several
other targets. It can modify the guest to make it bootable on KVM and
install virtio drivers so it will run quickly.
There is also a companion front-end called L<virt-p2v(1)> which comes
as an ISO, CD or PXE image that can be booted on physical machines to
virtualize those machines (physical to virtual, or p2v).
For in-place conversion, there is a separate tool called
L<virt-v2v-in-place(1)>.
=head2 Input and Output
You normally run virt-v2v with several I<-i*> options controlling the
input mode and also several I<-o*> options controlling the output
mode. In this sense, "input" refers to the source foreign hypervisor
such as VMware, and "output" refers to the target KVM-based management
system such as oVirt or OpenStack.
The input and output sides of virt-v2v are separate and unrelated.
Virt-v2v can read from any input and write to any output. Therefore
these sides of virt-v2v are documented separately in this manual.
Virt-v2v normally copies from the input to the output, called "copying
mode". In this case the source guest is always left unchanged.
In-place conversions may be done using L<virt-v2v-in-place(1)>.
=head2 Other virt-v2v topics
L<virt-v2v-support(1)> — Supported hypervisors, virtualization
management systems, guests.
L<virt-v2v-input-vmware(1)> — Input from VMware.
L<virt-v2v-input-xen(1)> — Input from Xen.
L<virt-v2v-output-local(1)> — Output to local files or local libvirt.
L<virt-v2v-output-rhv(1)> — Output to oVirt or RHV.
L<virt-v2v-output-openstack(1)> — Output to OpenStack.
L<virt-v2v-release-notes-1.42(1)> — Release notes for 1.42 release.
L<virt-v2v-release-notes-2.0(1)> — Release notes for 2.0 release.
=head1 EXAMPLES
=head2 Convert from VMware vCenter server to local libvirt
You have a VMware vCenter server called C<vcenter.example.com>, a
datacenter called C<Datacenter>, and an ESXi hypervisor called
C<esxi>. You want to convert a guest called C<vmware_guest> to run
locally under libvirt.
virt-v2v -ic vpx://vcenter.example.com/Datacenter/esxi vmware_guest
In this case you will most likely have to run virt-v2v as C<root>,
since it needs to talk to the system libvirt daemon and copy the guest
disks to F</var/lib/libvirt/images>.
For more information see L<virt-v2v-input-vmware(1)>.
=head2 Convert from VMware to RHV/oVirt
This is the same as the previous example, except you want to send the
guest to a RHV Data Domain using the RHV REST API. Guest network
interface(s) are connected to the target network called C<ovirtmgmt>.
virt-v2v -ic vpx://vcenter.example.com/Datacenter/esxi vmware_guest \
-o rhv-upload -oc https://ovirt-engine.example.com/ovirt-engine/api \
-os ovirt-data -op /tmp/ovirt-admin-password -of raw \
-oo rhv-cafile=/tmp/ca.pem --bridge ovirtmgmt
In this case the host running virt-v2v acts as a B<conversion server>.
For more information see L<virt-v2v-output-rhv(1)>.
=head2 Convert from ESXi hypervisor over SSH to local libvirt
You have an ESXi hypervisor called C<esxi.example.com> with SSH access
enabled. You want to convert from VMFS storage on that server to
a local file.
virt-v2v \
-i vmx -it ssh \
"ssh://root@esxi.example.com/vmfs/volumes/datastore1/guest/guest.vmx" \
-o local -os /var/tmp
The guest must not be running. Virt-v2v would I<not> need to be run
as root in this case.
For more information about converting from VMX files see
L<virt-v2v-input-vmware(1)>.
=head2 Convert disk image to OpenStack
Given a disk image from another hypervisor that you want to convert to
run on OpenStack (only KVM-based OpenStack is supported), you can run
virt-v2v inside an OpenStack VM (called C<v2v-vm> below), and do:
virt-v2v -i disk disk.img -o openstack -oo server-id=v2v-vm
See L<virt-v2v-output-openstack(1)>.
=head2 Convert disk image to disk image
Given a disk image from another hypervisor that you want to convert to
run on KVM, you have two options. The simplest way is to try:
virt-v2v -i disk disk.img -o local -os /var/tmp
where virt-v2v guesses everything about the input F<disk.img> and (in
this case) writes the converted result to F</var/tmp>.
A more complex method is to write some
L<libvirt XML|http://libvirt.org/formatdomain.html> describing the
input guest (if you can get the source hypervisor to provide you with
libvirt XML, then so much the better). You can then do:
virt-v2v -i libvirtxml guest-domain.xml -o local -os /var/tmp
Since F<guest-domain.xml> contains the path(s) to the guest disk
image(s) you do not need to specify the name of the disk image on the
command line.
To convert a local disk image and immediately boot it in local
qemu, do:
virt-v2v -i disk disk.img -o qemu -os /var/tmp -oo qemu-boot
=head1 OPTIONS
=over 4
=item B<--help>
Display help.
=item B<--bandwidth> bps
=item B<--bandwidth-file> filename
Some input methods are able to limit the network bandwidth they will
use statically or dynamically. In the first variant this sets the
bandwidth limit statically in bits per second. Formats like C<10M>
may be used (meaning 10 megabits per second).
In the second variant the bandwidth is limited dynamically from the
content of the file (also in bits per second, in the same formats
supported by the first variant). You may use both parameters
together, meaning: first limit to a static rate, then you can create
the file while virt-v2v is running to adjust the rate dynamically.
This is only supported for:
=over 4
=item *
L<input from Xen|virt-v2v-input-xen(1)>
=item *
L<input from VMware VMX|virt-v2v-input-vmware(1)/INPUT FROM VMWARE VMX>
when using the SSH transport method
=item *
L<input from VDDK|virt-v2v-input-vmware(1)/INPUT FROM VDDK>
=item *
I<-i libvirtxml> when using HTTP or HTTPS disks
=item *
L<input from VMware vCenter server|virt-v2v-input-vmware(1)/INPUT FROM VMWARE VCENTER SERVER>
=back
The options are silently ignored for other input methods.
=item B<-b> ...
=item B<--bridge> ...
See I<--network> below.
=item B<--colors>
=item B<--colours>
Use ANSI colour sequences to colourize messages. This is the default
when the output is a tty. If the output of the program is redirected
to a file, ANSI colour sequences are disabled unless you use this
option.
=item B<--compressed>
This is the same as I<-oo compressed>.
=item B<--echo-keys>
When prompting for keys and passphrases, virt-v2v normally turns
echoing off so you cannot see what you are typing. If you are not
worried about Tempest attacks and there is no one else in the room you
can specify this flag to see what you are typing.
Note this options only applies to keys and passphrases for encrypted
devices and partitions, not for passwords used to connect to remote
servers.
=item B<-i> B<disk>
Set the input method to I<disk>.
In this mode you can read a virtual machine disk image with no
metadata. virt-v2v tries to guess the best default metadata. This is
usually adequate but you can get finer control (eg. of memory and
vCPUs) by using I<-i libvirtxml> instead. Only guests that use a single
disk can be imported this way.
=item B<-i> B<libvirt>
Set the input method to I<libvirt>. This is the default.
In this mode you have to specify a libvirt guest name or UUID on the
command line. You may also specify a libvirt connection URI (see
I<-ic>).
=item B<-i> B<libvirtxml>
Set the input method to I<libvirtxml>.
In this mode you have to pass a libvirt XML file on the command line.
This file is read in order to get metadata about the source guest
(such as its name, amount of memory), and also to locate the input
disks. See L</Minimal XML for -i libvirtxml option> below.
=item B<-i> B<local>
This is the same as I<-i disk>.
=item B<-i> B<ova>
Set the input method to I<ova>.
In this mode you can read a VMware ova file. Virt-v2v will read the
ova manifest file and check the vmdk volumes for validity (checksums)
as well as analyzing the ovf file, and then convert the guest. See
L<virt-v2v-input-vmware(1)>.
=item B<-i> B<vmx>
Set the input method to I<vmx>.
In this mode you can read a VMware vmx file directly or over SSH.
This is useful when VMware VMs are stored on an NFS server which you
can mount directly, or where you have access by SSH to an ESXi
hypervisor. See L<virt-v2v-input-vmware(1)>.
=item B<-ic> libvirtURI
Specify a libvirt connection URI to use when reading the guest. This
is only used when S<I<-i libvirt>>.
Only local libvirt connections, VMware vCenter connections, or RHEL 5
Xen remote connections can be used. Other remote libvirt connections
will not work in general.
See also L<virt-v2v-input-vmware(1)>,
L<virt-v2v-input-xen(1)>.
=item B<-if> format
For I<-i disk> only, this specifies the format of the input disk
image. For other input methods you should specify the input
format in the metadata.
=item B<-io> OPTION=VALUE
Set input option(s) related to the current input mode or transport.
To display short help on what options are available you can use:
virt-v2v -it vddk -io "?"
=item B<-io vddk-libdir=>LIBDIR
Set the VDDK library directory. This directory should I<contain>
subdirectories called F<include>, F<lib64> etc., but do not include
F<lib64> actually in the parameter.
In most cases this parameter is required when using the I<-it vddk>
(VDDK) transport. See L<virt-v2v-input-vmware(1)> for details.
=item B<-io vddk-thumbprint=>xx:xx:xx:...
Set the thumbprint of the remote VMware server.
This parameter is required when using the I<-it vddk> (VDDK) transport.
See L<virt-v2v-input-vmware(1)> for details.
=item B<-io vddk-config=>FILENAME
=item B<-io vddk-cookie=>COOKIE
=item B<-io vddk-nfchostport=>PORT
=item B<-io vddk-port=>PORT
=item B<-io vddk-snapshot=>SNAPSHOT-MOREF
=item B<-io vddk-transports=>MODE:MODE:...
When using VDDK mode, these options are passed unmodified to the
L<nbdkit(1)> VDDK plugin. Please refer to L<nbdkit-vddk-plugin(1)>.
Do not use these options unless you know what you are doing. These
are all optional.
=item B<-ip> filename
Supply a file containing a password to be used when connecting to the
target hypervisor. If this is omitted then the input hypervisor may
ask for the password interactively. Note the file should contain the
whole password, B<without any trailing newline>, and for security the
file should have mode C<0600> so that others cannot read it.
=item B<-it> B<ssh>
When using I<-i vmx>, this enables the ssh transport.
See L<virt-v2v-input-vmware(1)>.
=item B<-it> B<vddk>
Use VMware VDDK as a transport to copy the input disks. See
L<virt-v2v-input-vmware(1)>. If you use this parameter then you
may need to use other I<-io vddk*> options to specify how to connect
through VDDK.
__INCLUDE:key-option.pod__
__INCLUDE:keys-from-stdin-option.pod__
Note I<--keys-from-stdin> only applies to keys and passphrases for
encrypted devices and partitions, not for passwords used to connect to
remote servers.
=item B<--mac> aa:bb:cc:dd:ee:ffB<:network:>out
=item B<--mac> aa:bb:cc:dd:ee:ffB<:bridge:>out
Map source NIC MAC address to a network or bridge.
See L</Networks and bridges> below.
=item B<--mac> aa:bb:cc:dd:ee:ffB<:ip:>ipaddr[,gw[,len[,ns,ns,...]]]
Force a particular interface (controlled by its MAC address) to have a
static IP address after boot.
The fields in the parameter are: C<ipaddr> is the IP address. C<gw>
is the optional gateway IP address. C<len> is the subnet mask length
(an integer). The final parameters are zero or more nameserver IP
addresses.
This option can be supplied zero or more times.
You only need to use this option for certain broken guests such as
Windows which are unable to preserve MAC to static IP address mappings
automatically. You don't need to use it if Windows is using DHCP. It
is currently ignored for Linux guests since they do not have this
problem.
=item B<--machine-readable>
=item B<--machine-readable>=format
This option is used to make the output more machine friendly
when being parsed by other programs. See
L</Machine readable output> below.
=item B<-n> in:out
=item B<-n> out
=item B<--network> in:out
=item B<--network> out
=item B<-b> in:out
=item B<-b> out
=item B<--bridge> in:out
=item B<--bridge> out
Map network (or bridge) called C<in> to network (or bridge) called
C<out>. If no C<in:> prefix is given, all other networks (or bridges)
are mapped to C<out>.
See L</Networks and bridges> below.
=item B<-o> B<disk>
This is the same as I<-o local>.
=item B<-o> B<glance>
This is a legacy option. You should probably use I<-o openstack>
instead.
Set the output method to OpenStack Glance. In this mode the converted
guest is uploaded to Glance. See L<virt-v2v-output-openstack(1)>.
=item B<-o> B<json>
Set the output method to I<json>.
In this mode, the converted guest is written to a local directory
specified by I<-os /dir> (the directory must exist), with a JSON file
containing the majority of the metadata that virt-v2v gathered during
the conversion.
See L<virt-v2v-output-local(1)>.
=item B<-o> B<libvirt>
Set the output method to I<libvirt>. This is the default.
In this mode, the converted guest is created as a libvirt guest. You
may also specify a libvirt connection URI (see I<-oc>).
See L<virt-v2v-output-local(1)>.
=item B<-o> B<local>
Set the output method to I<local>.
In this mode, the converted guest is written to a local directory
specified by I<-os /dir> (the directory must exist). The converted
guest’s disks are written as:
/dir/name-sda
/dir/name-sdb
[etc]
and a libvirt XML file is created containing guest metadata:
/dir/name.xml
where C<name> is the guest name.
=item B<-o> B<null>
Set the output method to I<null>.
The guest is converted and copied but the results are thrown away and
no metadata is written.
=item B<-o> B<openstack>
Set the output method to OpenStack. See L<virt-v2v-output-openstack(1)>.
=item B<-o> B<ovirt>
This is the same as I<-o rhv>.
=item B<-o> B<ovirt-upload>
This is the same as I<-o rhv-upload>.
=item B<-o> B<qemu>
Set the output method to I<qemu>.
This is similar to I<-o local>, except that a shell script is written
which you can use to boot the guest in qemu. The converted disks and
shell script are written to the directory specified by I<-os>.
When using this output mode, you can also specify the I<-oo qemu-boot>
option which boots the guest under qemu immediately.
=item B<-o> B<rhev>
This is the same as I<-o rhv>.
=item B<-o> B<rhv>
Set the output method to I<rhv>.
The converted guest is written to a RHV Export Storage Domain. The
I<-os> parameter must also be used to specify the location of the
Export Storage Domain. Note this does not actually import the guest
into RHV. You have to do that manually later using the UI.
See L<virt-v2v-output-rhv(1)>.
=item B<-o> B<rhv-upload>
Set the output method to I<rhv-upload>.
The converted guest is written directly to a RHV Data Domain.
This is a faster method than I<-o rhv>, but requires oVirt
or RHV E<ge> 4.2.
See L<virt-v2v-output-rhv(1)>.
=item B<-o> B<vdsm>
Set the output method to I<vdsm>.
This mode is similar to I<-o rhv>, but the full path to the
data domain must be given:
F</rhv/data-center/E<lt>data-center-uuidE<gt>/E<lt>data-domain-uuidE<gt>>.
This mode is only used when virt-v2v runs under VDSM control.
=item B<-oa> B<sparse>
=item B<-oa> B<preallocated>
Set the output file allocation mode. The default is C<sparse>.
=item B<-oc> URI
Specify a connection URI to use when writing the converted guest.
For S<I<-o libvirt>> this is the libvirt URI. Only local libvirt
connections can be used. Remote libvirt connections will not work.
See L<virt-v2v-output-local(1)> for further information.
=item B<-of> format
When converting the guest, convert the disks to the given format.
If not specified, then the input format is used.
=item B<-on> name
Rename the guest when converting it. If this option is not used then
the output name is the same as the input name.
=item B<-oo> OPTION=VALUE
Set output option(s) related to the current output mode.
To display short help on what options are available you can use:
virt-v2v -o rhv-upload -oo "?"
=item B<-oo compressed>
For outputs which support qcow2 format (I<-of qcow2>), this writes a
compressed qcow2 file. It is the equivalent to the I<-c> option of
L<qemu-img(1)>.
=item B<-oo guest-id=>C<ID>
For I<-o openstack> (L<virt-v2v-output-openstack(1)>) only, set a guest ID
which is saved on each Cinder volume in the C<virt_v2v_guest_id>
volume property.
=item B<-oo qemu-boot>
When using I<-o qemu> only, this boots the guest immediately after
virt-v2v finishes.
=item B<-oo verify-server-certificate>
=item B<-oo verify-server-certificate=>C<true|false>
For I<-o openstack> (L<virt-v2v-output-openstack(1)>) only, this can
be used to disable SSL certification validation when connecting to
OpenStack by specifying I<-oo verify-server-certificate=false>.
=item B<-oo os->*B<=>*
For I<-o openstack> (L<virt-v2v-output-openstack(1)>) only, set optional
OpenStack authentication. For example I<-oo os-username=>NAME is
equivalent to C<openstack --os-username=NAME>.
=item B<-oo rhv-cafile=>F<ca.pem>
For I<-o rhv-upload> (L<virt-v2v-output-rhv(1)>) only, the F<ca.pem> file
(Certificate Authority), copied from F</etc/pki/ovirt-engine/ca.pem>
on the oVirt engine.
=item B<-oo rhv-cluster=>C<CLUSTERNAME>
For I<-o rhv-upload> (L<virt-v2v-output-rhv(1)>) only, set the RHV Cluster
Name. If not given it uses C<Default>.
=item B<-oo rhv-proxy>
For I<-o rhv-upload> (L<virt-v2v-output-rhv(1)>) only, proxy the
upload through oVirt Engine. This is slower than uploading directly
to the oVirt node but may be necessary if you do not have direct
network access to the nodes.
=item B<-oo rhv-verifypeer>
For I<-o rhv-upload> (L<virt-v2v-output-rhv(1)>) only, verify the oVirt/RHV
server’s identity by checking the server‘s certificate against the
Certificate Authority.
=item B<-oo server-id=>C<NAME|UUID>
For I<-o openstack> (L<virt-v2v-output-openstack(1)>) only, set the name
of the conversion appliance where virt-v2v is running.
=item B<-oo vdsm-compat=0.10>
=item B<-oo vdsm-compat=1.1>
If I<-o vdsm> and the output format is qcow2, then we add the qcow2
I<compat=0.10> option to the output file for compatibility with RHEL 6
(see L<https://bugzilla.redhat.com/1145582>).
If I<-oo vdsm-compat=1.1> is used then modern qcow2 (I<compat=1.1>)
files are generated instead.
Currently I<-oo vdsm-compat=0.10> is the default, but this will change
to I<-oo vdsm-compat=1.1> in a future version of virt-v2v (when we can
assume that everyone is using a modern version of qemu).
B<Note this option only affects I<-o vdsm> output>. All other output
modes (including I<-o rhv>) generate modern qcow2 I<compat=1.1>
files, always.
If this option is available, then C<vdsm-compat-option> will appear in
the I<--machine-readable> output.
=item B<-oo vdsm-image-uuid=>UUID
=item B<-oo vdsm-vol-uuid=>UUID
=item B<-oo vdsm-vm-uuid=>UUID
=item B<-oo vdsm-ovf-output=>DIR
Normally the RHV output mode chooses random UUIDs for the target
guest. However VDSM needs to control the UUIDs and passes these
parameters when virt-v2v runs under VDSM control. The parameters
control:
=over 4
=item *
the image directory of each guest disk (I<-oo vdsm-image-uuid>) (this
option is passed once for each guest disk)
=item *
UUIDs for each guest disk (I<-oo vdsm-vol-uuid>) (this option
is passed once for each guest disk)
=item *
the OVF file name (I<-oo vdsm-vm-uuid>).
=item *
the OVF output directory (default current directory) (I<-oo vdsm-ovf-output>).
=back
The format of UUIDs is: C<12345678-1234-1234-1234-123456789abc> (each
hex digit can be C<0-9> or C<a-f>), conforming to S<OSF DCE 1.1>.
These options can only be used with I<-o vdsm>.
=item B<-oo vdsm-ovf-flavour=>flavour
This option controls the format of the OVF generated at the end of conversion.
Currently there are two possible flavours:
=over 4
=item rhvexp
The OVF format used in RHV export storage domain.
=item ovirt
The OVF format understood by oVirt REST API.
=back
For backward compatibility the default is I<rhvexp>, but this may change in
the future.
=item B<-op> file
Supply a file containing a password to be used when connecting to the
target hypervisor. Note the file should contain the whole password,
B<without any trailing newline>, and for security the file should have
mode C<0600> so that others cannot read it.
=item B<-os> storage
The location of the storage for the converted guest.
For I<-o libvirt>, this is a libvirt directory pool
(see S<C<virsh pool-list>>) or pool UUID.
For I<-o json>, I<-o local> and I<-o qemu>, this is a directory name.
The directory must exist.
For I<-o rhv-upload>, this is the name of the destination Storage
Domain.
For I<-o openstack>, this is the optional Cinder volume type.
For I<-o rhv>, this can be an NFS path of the Export Storage Domain
of the form C<E<lt>hostE<gt>:E<lt>pathE<gt>>, eg:
rhv-storage.example.com:/rhv/export
The NFS export must be mountable and writable by the user and host
running virt-v2v, since the virt-v2v program has to actually mount it
when it runs. So you probably have to run virt-v2v as C<root>.
B<Or:> You can mount the Export Storage Domain yourself, and point
I<-os> to the mountpoint. Note that virt-v2v will still need to write
to this remote directory, so virt-v2v will still need to run as
C<root>.
You will get an error if virt-v2v is unable to mount/write to the
Export Storage Domain.
=item B<--print-source>
Print information about the source guest and stop. This option is
useful when you are setting up network and bridge maps.
See L</Networks and bridges>.
=item B<--qemu-boot>
This is the same as I<-oo qemu-boot>.
=item B<-q>
=item B<--quiet>
This disables progress bars and other unnecessary output.
=item B<--root ask>
=item B<--root single>
=item B<--root first>
=item B<--root> /dev/sdX
=item B<--root> /dev/VG/LV
Choose the root filesystem to be converted.
In the case where the virtual machine is dual-boot or multi-boot, or
where the VM has other filesystems that look like operating systems,
this option can be used to select the root filesystem (a.k.a. C<C:>
drive or F</>) of the operating system that is to be converted. The
Windows Recovery Console, certain attached DVD drives, and bugs in
libguestfs inspection heuristics, can make a guest look like a
multi-boot operating system.
The default in virt-v2v E<le> 0.7.1 was S<I<--root single>>, which
causes virt-v2v to die if a multi-boot operating system is found.
Since virt-v2v E<ge> 0.7.2 the default is now S<I<--root ask>>: If the
VM is found to be multi-boot, then virt-v2v will stop and list the
possible root filesystems and ask the user which to use. This
requires that virt-v2v is run interactively.
S<I<--root first>> means to choose the first root device in the case
of a multi-boot operating system. Since this is a heuristic, it may
sometimes choose the wrong one.
You can also name a specific root device, eg. S<I<--root /dev/sda2>>
would mean to use the second partition on the first hard drive. If
the named root device does not exist or was not detected as a root
device, then virt-v2v will fail.
Note that there is a bug in grub which prevents it from successfully
booting a multiboot system if virtio is enabled. Grub is only able to
boot an operating system from the first virtio disk. Specifically,
F</boot> must be on the first virtio disk, and it cannot chainload an
OS which is not in the first virtio disk.
=item B<-v>
=item B<--verbose>
Enable verbose messages for debugging.
=item B<-V>
=item B<--version>
Display version number and exit.
=item B<--wrap>
Wrap error, warning, and informative messages. This is the default
when the output is a tty. If the output of the program is redirected
to a file, wrapping is disabled unless you use this option.
=item B<-x>
Enable tracing of libguestfs API calls.
=back
=head1 NOTES
=head2 Xen paravirtualized guests
Older versions of virt-v2v could turn a Xen paravirtualized (PV) guest
into a KVM guest by installing a new kernel. This version of virt-v2v
does I<not> attempt to install any new kernels. Instead it will give
you an error if there are I<only> Xen PV kernels available.
Therefore before conversion you should check that a regular kernel is
installed. For some older Linux distributions, this means installing
a kernel from the table below:
RHEL 3 (Does not apply, as there was no Xen PV kernel)
RHEL 4 i686 with > 10GB of RAM: install 'kernel-hugemem'
i686 SMP: install 'kernel-smp'
other i686: install 'kernel'
x86-64 SMP with > 8 CPUs: install 'kernel-largesmp'
x86-64 SMP: install 'kernel-smp'
other x86-64: install 'kernel'
RHEL 5 i686: install 'kernel-PAE'
x86-64: install 'kernel'
SLES 10 i586 with > 10GB of RAM: install 'kernel-bigsmp'
i586 SMP: install 'kernel-smp'
other i586: install 'kernel-default'
x86-64 SMP: install 'kernel-smp'
other x86-64: install 'kernel-default'
SLES 11+ i586: install 'kernel-pae'
x86-64: install 'kernel-default'
Windows (Does not apply, as there is no Xen PV Windows kernel)
=head2 Enabling virtio
"Virtio" is the name for a set of drivers which make disk (block
device), network and other guest operations work much faster on KVM.
Older versions of virt-v2v could install these drivers for certain
Linux guests. This version of virt-v2v does I<not> attempt to install
new Linux kernels or drivers, but will warn you if they are not
installed already.
In order to enable virtio, and hence improve performance of the guest
after conversion, you should ensure that the B<minimum> versions of
packages are installed I<before> conversion, by consulting the table
below.
RHEL 3 No virtio drivers are available
RHEL 4 kernel >= 2.5.9-89.EL
lvm2 >= 2.02.42-5.el4
device-mapper >= 1.02.28-2.el4
selinux-policy-targeted >= 1.17.30-2.152.el4
policycoreutils >= 1.18.1-4.13
RHEL 5 kernel >= 2.6.18-128.el5
lvm2 >= 2.02.40-6.el5
selinux-policy-targeted >= 2.4.6-203.el5
RHEL 6+ All versions support virtio
Fedora All versions support virtio
SLES 11+ All versions support virtio
SLES 10 kernel >= 2.6.16.60-0.85.1
OpenSUSE 11+ All versions support virtio
OpenSUSE 10 kernel >= 2.6.25.5-1.1
Debian 6+ All versions support virtio
Ubuntu 10.04+ All versions support virtio
Windows Drivers are installed from the ISO or directory pointed
to by the "VIRTIO_WIN" environment variable if present.
If the "VIRTIO_WIN" environment variable is absent
(which is the recommended setting), then libosinfo is
consulted first, for driver files that are locally
available on the conversion host.
=head2 RHEL 4: SELinux relabel appears to hang forever
In RHEL E<le> 4.7 there was a bug which causes SELinux relabelling
to appear to hang forever at:
*** Warning -- SELinux relabel is required. ***
*** Disabling security enforcement. ***
*** Relabeling could take a very long time, ***
*** depending on file system size. ***
In reality it is waiting for you to press a key (but there is no
visual indication of this). You can either hit the C<[Return]> key,
at which point the guest will finish relabelling and reboot, or you
can install policycoreutils E<ge> 1.18.1-4.13 before starting the v2v
conversion. See also
L<https://bugzilla.redhat.com/show_bug.cgi?id=244636>
=head2 Debian and Ubuntu
=head3 "warning: could not determine a way to update the configuration of Grub2"
Currently, virt-v2v has no way to set the default kernel in Debian
and Ubuntu guests using GRUB 2 as bootloader. This means that
virt-v2v will not change the default kernel used for booting, even
in case it is not the best kernel available on the guest.
A recommended procedure is, before using virt-v2v, to check that the
boot kernel is the best kernel available in the guest (for example
by making sure the guest is up-to-date).
=head3 "vsyscall attempted with vsyscall=none"
When run on a recent Debian host virt-v2v may fail to convert guests
which were created before 2013. In the debugging output you will see
a crash message similar to:
vsyscall attempted with vsyscall=none ip:...
segfault at ...
This is caused because Debian removed support for running old binaries
which used the legacy vsyscall page to call into the kernel.
You can work around this problem by running this command before
running virt-v2v:
export LIBGUESTFS_APPEND="vsyscall=emulate"
For more information, see L<https://bugzilla.redhat.com/1592061>
=head2 Windows
=head3 Windows E<ge> 8 Fast Startup is incompatible with virt-v2v
Guests which use the Windows E<ge> 8 "Fast Startup" feature (or guests
which are hibernated) cannot be converted with virt-v2v. You will see
an error:
virt-v2v: error: unable to mount the disk image for writing. This has
probably happened because Windows Hibernation or Fast Restart is being
used in this guest. You have to disable this (in the guest) in order
to use virt-v2v.
As the message says, you need to boot the guest and disable the "Fast
Startup" feature (Control Panel → Power Options → Choose what the
power buttons do → Change settings that are currently unavailable →
Turn on fast startup), and shut down the guest, and then you will be
able to convert it.
For more information, see:
L<guestfs(3)/WINDOWS HIBERNATION AND WINDOWS 8 FAST STARTUP>.
=head3 Boot failure: 0x0000007B
This boot failure is caused by Windows being unable to find or load
the right disk driver (eg. F<viostor.sys>). If you experience this
error, here are some things to check:
=over 4
=item *
First ensure that the guest boots on the source hypervisor before
conversion.
=item *