1virt-p2v(1)                 Virtualization Support                 virt-p2v(1)
2
3
4

NAME

6       virt-p2v - Convert a physical machine to use KVM
7

SYNOPSIS

9        virt-p2v
10
11        virt-p2v.iso
12

DESCRIPTION

14       Virt-p2v converts a physical machine to run virtualized on KVM, managed
15       by libvirt, OpenStack, oVirt, Red Hat Virtualisation (RHV), or one of
16       the other targets supported by virt-v2v(1).
17
18       Normally you don’t run the virt-p2v program directly.  Instead you have
19       to boot the physical machine using the bootable CD-ROM, ISO or PXE
20       image.  This bootable image contains the virt-p2v binary and runs it
21       automatically.  Booting from a CD-ROM/etc is required because the disks
22       which are being converted must be quiescent.  It is not safe to try to
23       convert a running physical machine where other programs may be
24       modifying the disk content at the same time.
25
26       This manual page documents running the virt-p2v program.  To create the
27       bootable image you should look at virt-p2v-make-disk(1) or
28       virt-p2v-make-kickstart(1).
29

NETWORK SETUP

31       Virt-p2v runs on the physical machine which you want to convert.  It
32       has to talk to another server called the "conversion server" which must
33       have virt-v2v(1) installed on it.  It always talks to the conversion
34       server over SSH:
35
36        ┌──────────────┐                  ┌─────────────────┐
37        │ virt-p2v     │                  │ virt-v2v        │
38        │ (physical    │  ssh connection  │ (conversion     │
39        │  server)   ╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍▶ server)       │
40        └──────────────┘                  └─────────────────┘
41
42       The virt-v2v program on the conversion server does the actual
43       conversion (physical to virtual, and virtual to virtual conversions are
44       sufficiently similar that we use the same program to do both).
45
46       The SSH connection is always initiated from the physical server.  All
47       data is transferred over the SSH connection.  In terms of firewall and
48       network configuration, you only need to ensure that the physical server
49       has access to a port (usually TCP port 22) on the conversion server.
50       Note that the physical machine may reconnect several times during the
51       conversion process.
52
53       The reverse port forwarding feature of ssh (ie. "ssh -R") is required
54       by virt-p2v, and it will not work if this is disabled on the conversion
55       server.  ("AllowTcpForwarding" must be "yes" in the sshd_config(5) file
56       on the conversion server).
57
58       The scp (secure copy) feature of ssh is required by virt-p2v so it can
59       send over small files (this is not the method by which disks are
60       copied).
61
62       The conversion server does not need to be a physical machine.  It could
63       be a virtual machine, as long as it has sufficient memory and disk
64       space to do the conversion, and as long as the physical machine can
65       connect directly to its SSH port.  (See also "Resource requirements" in
66       virt-v2v(1)).
67
68       Because all of the data on the physical server’s hard drive(s) has to
69       be copied over the network, the speed of conversion is largely
70       determined by the speed of the network between the two machines.
71

GUI INTERACTIVE CONFIGURATION

73       When you start virt-p2v, you'll see a graphical configuration dialog
74       that walks you through connection to the conversion server, asks for
75       the password, which local hard disks you want to convert, and other
76       things like the name of the guest to create and the number of virtual
77       CPUs to give it.
78
79   SSH CONFIGURATION DIALOG
80       When virt-p2v starts up in GUI mode, the first dialog looks like this:
81
82        ┌─────────────────────────────────────────────────────────────┐
83        │                           virt-p2v                          │
84        │                                                             │
85        │ Conversion server: [____________________________] : [22___] │
86        │                                                             │
87        │         User name: [root__________________________________] │
88        │                                                             │
89        │          Password: [______________________________________] │
90        │                                                             │
91        │  SSH Identity URL: [______________________________________] │
92        │                                                             │
93
94       In the fields above, you must enter the details of the conversion
95       server: the hostname, SSH port number, remote user name, and either the
96       password or SSH identity (private key) URL.  The conversion server must
97       have an up to date version of virt-v2v.
98
99       Normally you must log in to the conversion server as root, but if you
100       check the following box:
101
102        │                                                             │
103        │                    [ ] Use sudo when running virt-v2v       │
104        │                                                             │
105
106       then you can log in as another user, and virt-p2v will use the sudo(8)
107       command to elevate privileges to root.  Note that sudo must not require
108       a password.
109
110       It is also possible to run virt-v2v on the conversion server entirely
111       as non-root, but output modes may be limited.  Consult the virt-v2v(1)
112       manual page for details.
113
114       At the bottom of the dialog are these buttons:
115
116        │                                                             │
117        │                     [ Test connection ]                     │
118        │                                                             │
119        │ [ Configure network ] [ XTerm ] [ About virt-p2v ] [ Next ] │
120        │                                                             │
121        └─────────────────────────────────────────────────────────────┘
122
123       You must press the "Test connection" button first to test the SSH
124       connection to the conversion server.  If that is successful (ie. you
125       have supplied the correct server name, user name, password, etc., and a
126       suitable version of virt-v2v is available remotely) then press the
127       "Next" button to move to the next dialog.
128
129       You can use the "Configure network" button if you need to assign a
130       static IP address to the physical machine, or use Wifi, bonding or
131       other network features.
132
133       The "XTerm" button opens a shell which can be used for diagnostics,
134       manual network configuration, and so on.
135
136   DISK AND NETWORK CONFIGURATION DIALOG
137       The second configuration dialog lets you configure the details of
138       conversion, including what to convert and where to send the guest.
139
140       In the left hand column, starting at the top, the target properties let
141       you select the name of the guest (ie. after conversion) and how many
142       virtual CPUs and how much RAM to give it.  The defaults come from the
143       physical machine, and you can usually leave them unchanged:
144
145        ┌─────────────────────────────────────── ─ ─ ─ ─
146        │ Target properties:
147
148        │        Name: [hostname______________]
149
150        │     # vCPUs: [4_____________________]
151
152        │ Memory (MB): [16384_________________]
153
154
155       The second panel on the left controls the virt-v2v output options.  To
156       understand these options it is a really good idea to read the
157       virt-v2v(1) manual page.  You can leave the options at the default to
158       create a guest as a disk image plus libvirt XML file located in
159       /var/tmp on the conversion host.  This is a good idea if you are a
160       first-time virt-p2v user.
161
162
163        │ Virt-v2v output options:
164
165        │          Output to (-o): [local             ▼]
166
167        │      Output conn. (-oc): [___________________]
168
169        │    Output storage (-os): [/var/tmp___________]
170
171        │     Output format (-of): [___________________]
172
173        │ Output allocation (-oa): [sparse            ▼]
174
175
176       All output options and paths are relative to the conversion server (not
177       to the physical server).
178
179       Finally in the left hand column is an information box giving the
180       version of virt-p2v (on the physical server) and virt-v2v (on the
181       conversion server).  You should supply this information when reporting
182       bugs.
183
184       In the right hand column are three panels which control what hard
185       disks, removable media devices, and network interfaces, will be created
186       in the output guest.  Normally leaving these at the default settings is
187       fine.
188
189        ─ ─ ───────────────────────────────────────┐
190            Fixed hard disks                       │
191
192            Convert  Device                        │
193            [✔]      sda                           │
194                     1024G HITACHI                 │
195                     s/n 12345                     │
196            [✔]      sdb                           │
197                     119G HITACHI                  │
198                     s/n 12346                     │
199
200
201       Normally you would want to convert all hard disks.  If you want
202       virt-p2v to completely ignore a local hard disk, uncheck it.  The hard
203       disk that contains the operating system must be selected.  If a hard
204       disk is part of a RAID array or LVM volume group (VG), then either all
205       hard disks in that array/VG must be selected, or none of them.
206
207
208            Removable media                        │
209
210            Convert  Device                        │
211            [✔]      sr0                           │
212
213
214       If the physical machine has CD or DVD drives, then you can use the
215       Removable media panel to create corresponding drives on the guest after
216       conversion.  Note that any data CDs/DVDs which are mounted in the
217       drives are not copied over.
218
219
220            Network interfaces                     │
221
222            Convert  Device Connect to ...         |
223            [✔]      em1    [default_____________] │
224            [ ]      wlp3s0 [default_____________] │
225
226
227       In the Network interfaces panel, select the network interfaces that
228       should be created in the guest after conversion.  You can also connect
229       these to target hypervisor networks (for further information about this
230       feature, see "Networks and bridges" in virt-v2v(1)).
231
232       On supported hardware, left-clicking on the device name (eg. "em1")
233       causes a light to start flashing on the physical interface, allowing
234       the interface to be identified by the operator.
235
236       When you are ready to begin the conversion, press the "Start
237       conversion" button:
238
239
240                    [ Back ]  [ Start conversion ] │
241
242        ─ ─ ───────────────────────────────────────┘
243
244   CONVERSION RUNNING DIALOG
245       When conversion is running you will see this dialog:
246
247        ┌────────────────────────────────────────────────────────┐
248        │                      virt-p2v                          │
249        │                                                        │
250        │  ┌──────────────────────────────────────────────────┐  │
251        │  │                                                 ▲│  │
252        │  │                                                  │  │
253        │  │                                                  │  │
254        ∼  ∼                                                  ∼  ∼
255        │  │                                                  │  │
256        │  │                                                  │  │
257        │  │                                                 ▼│  │
258        │  └──────────────────────────────────────────────────┘  │
259        │                                                        │
260        │ Log files ... to /tmp/virt-p2v-xxx                     │
261        │                                                        │
262        │ Doing conversion ...                                   │
263        │                                                        │
264        │                                 [ Cancel conversion ]  │
265        │                                                        │
266        └────────────────────────────────────────────────────────┘
267
268       In the main scrolling area you will see messages from the virt-v2v
269       process.
270
271       Below the main area, virt-p2v shows you the location of the directory
272       on the conversion server that contains log files and other debugging
273       information.  Below that is the current status and a button for
274       cancelling conversion.
275
276       Once conversion has finished, you should shut down the physical
277       machine.  If conversion is successful, you should never reboot it.
278

KERNEL COMMAND LINE CONFIGURATION

280       If you don’t want to configure things using the graphical UI, an
281       alternative is to configure through the kernel command line.  This is
282       especially convenient if you are converting a lot of physical machines
283       which are booted using PXE.
284
285       Where exactly you set command line arguments depends on your PXE
286       implementation, but for pxelinux you put them in the "APPEND" field in
287       the pxelinux.cfg file.  For example:
288
289        DEFAULT p2v
290        TIMEOUT 20
291        PROMPT 0
292        LABEL p2v
293          KERNEL vmlinuz0
294          APPEND initrd=initrd0.img [....] p2v.server=conv.example.com p2v.password=secret p2v.o=libvirt
295
296       You have to set some or all of the following command line arguments:
297
298       p2v.remote.server=SERVER
299       p2v.server=SERVER
300           The name or IP address of the conversion server.
301
302           This is always required if you are using the kernel configuration
303           method.  If virt-p2v does not find this on the kernel command line
304           then it switches to the GUI (interactive) configuration method.
305
306       p2v.remote.port=PORT
307       p2v.port=PORT
308           The SSH port number on the conversion server (default: 22).
309
310       p2v.auth.username=USERNAME
311       p2v.username=USERNAME
312           The SSH username that we log in as on the conversion server
313           (default: "root").
314
315       p2v.auth.password=PASSWORD
316       p2v.password=PASSWORD
317           The SSH password that we use to log in to the conversion server.
318
319           The default is to try with no password.  If this fails then
320           virt-p2v will ask the user to type the password (probably several
321           times during conversion).
322
323           This setting is ignored if "p2v.auth.identity.url" is present.
324
325       p2v.auth.identity.url=URL
326       p2v.identity=URL
327           Provide a URL pointing to an SSH identity (private key) file.  The
328           URL is interpreted by curl(1) so any URL that curl supports can be
329           used here, including "https://" and "file://".  For more
330           information on using SSH identities, see "SSH IDENTITIES" below.
331
332           If "p2v.auth.identity.url" is present, it overrides
333           "p2v.auth.password".  There is no fallback.
334
335       p2v.auth.sudo
336       p2v.sudo
337           Use "p2v.sudo" to tell virt-p2v to use sudo(8) to gain root
338           privileges on the conversion server after logging in as a non-root
339           user (default: do not use sudo).
340
341       p2v.guestname=GUESTNAME
342       p2v.name=GUESTNAME
343           The name of the guest that is created.  The default is to try to
344           derive a name from the physical machine’s hostname (if possible)
345           else use a randomly generated name.
346
347       p2v.vcpus=N
348           The number of virtual CPUs to give to the guest.  The default is to
349           use the same as the number of physical CPUs.
350
351       p2v.memory=n(M|G)
352           The size of the guest memory.  You must specify the unit such as
353           megabytes or gigabytes by using for example "p2v.memory=1024M" or
354           "p2v.memory=1G".
355
356           The default is to use the same amount of RAM as on the physical
357           machine.
358
359       p2v.cpu.vendor=VENDOR
360           The vCPU vendor, eg. "Intel" or "AMD".  The default is to use the
361           same CPU vendor as the physical machine.
362
363       p2v.cpu.model=MODEL
364           The vCPU model, eg. "IvyBridge".  The default is to use the same
365           CPU model as the physical machine.
366
367       p2v.cpu.sockets=N
368           Number of vCPU sockets to use.  The default is to use the same as
369           the physical machine.
370
371       p2v.cpu.cores=N
372           Number of vCPU cores to use.  The default is to use the same as the
373           physical machine.
374
375       p2v.cpu.threads=N
376           Number of vCPU hyperthreads to use.  The default is to use the same
377           as the physical machine.
378
379       p2v.cpu.acpi
380           Whether to enable ACPI in the remote virtual machine.  The default
381           is to use the same as the physical machine.
382
383       p2v.cpu.apic
384           Whether to enable APIC in the remote virtual machine.  The default
385           is to use the same as the physical machine.
386
387       p2v.cpu.pae
388           Whether to enable PAE in the remote virtual machine.  The default
389           is to use the same as the physical machine.
390
391       p2v.rtc.basis=(unknown|utc|localtime)
392           Set the basis of the Real Time Clock in the virtual machine.  The
393           default is to try to detect this setting from the physical machine.
394
395       p2v.rtc.offset=[+|-]HOURS
396           The offset of the Real Time Clock from UTC.  The default is to try
397           to detect this setting from the physical machine.
398
399       p2v.disks=sda,sdb,...
400           A list of physical hard disks to convert, for example:
401
402            p2v.disks=sda,sdc
403
404           The default is to convert all local hard disks that are found.
405
406       p2v.removable=sra,srb,...
407           A list of removable media to convert.  The default is to create
408           virtual removable devices for every physical removable device
409           found.  Note that the content of removable media is never copied
410           over.
411
412       p2v.interfaces=em1,...
413           A list of network interfaces to convert.  The default is to create
414           virtual network interfaces for every physical network interface
415           found.
416
417       p2v.network_map=interface:target,...
418       p2v.network=interface:target,...
419           Controls how network interfaces are connected to virtual networks
420           on the target hypervisor.  The default is to connect all network
421           interfaces to the target "default" network.
422
423           You give a comma-separated list of "interface:target" pairs, plus
424           optionally a default target.  For example:
425
426            p2v.network=em1:ovirtmgmt
427
428           maps interface "em1" to target network "ovirtmgmt".
429
430            p2v.network=em1:ovirtmgmt,em2:management,other
431
432           maps interface "em1" to "ovirtmgmt", and "em2" to "management", and
433           any other interface that is found to "other".
434
435       p2v.output.type=(libvirt|local|...)
436       p2v.o=(libvirt|local|...)
437           Set the output mode.  This is the same as the virt-v2v -o option.
438           See "OPTIONS" in virt-v2v(1).
439
440           If not specified, the default is "local", and the converted guest
441           is written to /var/tmp.
442
443       p2v.output.allocation=(none|sparse|preallocated)
444       p2v.oa=(none|sparse|preallocated)
445           Set the output allocation mode.  This is the same as the virt-v2v
446           -oa option.  See "OPTIONS" in virt-v2v(1).
447
448       p2v.output.connection=URI
449       p2v.oc=URI
450           Set the output connection libvirt URI.  This is the same as the
451           virt-v2v -oc option.  See "OPTIONS" in virt-v2v(1) and
452           http://libvirt.org/uri.html
453
454       p2v.output.format=(raw|qcow2|...)
455       p2v.of=(raw|qcow2|...)
456           Set the output format.  This is the same as the virt-v2v -of
457           option.  See "OPTIONS" in virt-v2v(1).
458
459       p2v.output.storage=STORAGE
460       p2v.os=STORAGE
461           Set the output storage.  This is the same as the virt-v2v -os
462           option.  See "OPTIONS" in virt-v2v(1).
463
464           If not specified, the default is /var/tmp (on the conversion
465           server).
466
467       p2v.pre=COMMAND
468       p2v.pre="COMMAND ARG ..."
469           Select a pre-conversion command to run.  Any command or script can
470           be specified here.  If the command contains spaces, you must quote
471           the whole command with double quotes.  The default is not to run
472           any command.
473
474       p2v.post=poweroff
475       p2v.post=reboot
476       p2v.post=COMMAND
477       p2v.post="COMMAND ARG ..."
478           Select a post-conversion command to run if conversion is
479           successful.  This can be any command or script.  If the command
480           contains spaces, you must quote the whole command with double
481           quotes.
482
483           If virt-p2v is running as root, and the command line was set from
484           /proc/cmdline (not --cmdline), then the default is to run the
485           poweroff(8) command.  Otherwise the default is not to run any
486           command.
487
488       p2v.fail=COMMAND
489       p2v.fail="COMMAND ARG ..."
490           Select a post-conversion command to run if conversion fails.  Any
491           command or script can be specified here.  If the command contains
492           spaces, you must quote the whole command with double quotes.  The
493           default is not to run any command.
494
495       ip=dhcp
496           Use DHCP for configuring the network interface (this is the
497           default).
498

SSH IDENTITIES

500       As a somewhat more secure alternative to password authentication, you
501       can use an SSH identity (private key) for authentication.
502
503       First create a key pair.  It must have an empty passphrase:
504
505        ssh-keygen -t rsa -N '' -f id_rsa
506
507       This creates a private key ("id_rsa") and a public key ("id_rsa.pub")
508       pair.
509
510       The public key should be appended to the "authorized_keys" file on the
511       virt-v2v conversion server (usually to "/root/.ssh/authorized_keys").
512
513       For distributing the private key, there are four scenarios from least
514       secure to most secure:
515
516       1.  Not using SSH identities at all, ie. password authentication.
517
518           Anyone who can sniff the PXE boot parameters from the network or
519           observe the password some other way can log in to the virt-v2v
520           conversion server.
521
522       2.  SSH identity embedded in the virt-p2v ISO or disk image.  In the
523           GUI, use:
524
525            │          Password: [    <leave this field blank>       ] │
526            │                                                          │
527            │  SSH Identity URL: [file:///var/tmp/id_rsa_____________] │
528
529           or on the kernel command line:
530
531            p2v.identity=file:///var/tmp/id_rsa
532
533           The SSH private key can still be sniffed from the network if using
534           standard PXE.
535
536       3.  SSH identity downloaded from a website.  In the GUI, use:
537
538            │          Password: [    <leave this field blank>       ] │
539            │                                                          │
540            │  SSH Identity URL: [https://internal.example.com/id_rsa] │
541
542           or on the kernel command line:
543
544            p2v.identity=https://internal.example.com/id_rsa
545
546           Anyone could still download the private key and use it to log in to
547           the virt-v2v conversion server, but you could provide some extra
548           security by configuring the web server to only allow connections
549           from P2V machines.
550
551           Note that ssh-keygen(1) creates the "id_rsa" (private key) file
552           with mode 0600.  If you simply copy the file to a webserver, the
553           webserver will not serve it.  It will reply with "403 Forbidden"
554           errors.  You will need to change the mode of the file to make it
555           publicly readable, for example by using:
556
557            chmod 0644 id_rsa
558
559       4.  SSH identity embedded in the virt-p2v ISO or disk image (like 2.),
560           and use of secure PXE, PXE over separate physical network, or
561           sneakernet to distribute virt-p2v to the physical machine.
562
563       Both virt-p2v-make-disk(1) and virt-p2v-make-kickstart(1) have the same
564       option --inject-ssh-identity for injecting the private key into the
565       virt-p2v disk image / ISO.  See also the following manual sections:
566
567       "ADDING AN SSH IDENTITY" in virt-p2v-make-disk(1)
568
569       "ADDING AN SSH IDENTITY" in virt-p2v-make-kickstart(1)
570

COMMON PROBLEMS

572   Timeouts
573       As described below (see "HOW VIRT-P2V WORKS") virt-p2v makes several
574       long-lived ssh connections to the conversion server.  If these
575       connections time out then virt-p2v will fail.
576
577       To test if a timeout might be causing problems, open an XTerm on the
578       virt-p2v machine, "ssh root@conversion-server", and leave it for at
579       least an hour.  If the session disconnects without you doing anything,
580       then there is a timeout which you should turn off.
581
582       Timeouts happen because:
583
584       "TIMEOUT" or "TMOUT" environment variable
585           Check if one of these environment variables is set in the root
586           shell on the conversion server.
587
588       sshd "ClientAlive*" setting
589           Check for "ClientAlive*" settings in "/etc/ssh/sshd_config" on the
590           conversion server.
591
592       Firewall or NAT settings
593           Check if there is a firewall or NAT box between virt-p2v and the
594           conversion server, and if this firewall drops idle connections
595           after a too-short time.
596
597           virt-p2v ≥ 1.36 attempts to work around firewall timeouts by
598           sending ssh keepalive messages every 5 minutes.
599

OPTIONS

601       --help
602           Display help.
603
604       --cmdline=CMDLINE
605           This is used for debugging. Instead of parsing the kernel command
606           line from /proc/cmdline, parse the string parameter "CMDLINE".
607
608       --colors
609       --colours
610           Use ANSI colour sequences to colourize messages.  This is the
611           default when the output is a tty.  If the output of the program is
612           redirected to a file, ANSI colour sequences are disabled unless you
613           use this option.
614
615       --iso
616           This flag is passed to virt-p2v when it is launched inside the
617           virt-p2v ISO environment, ie. when it is running on a real physical
618           machine (and thus not when testing).  It enables various dangerous
619           features such as the Shutdown popup button.
620
621       --nbd=server[,server...]
622           Select which NBD server is used.  By default the following servers
623           are checked and the first one found is used:
624           --nbd=qemu-nbd,qemu-nbd-no-sa,nbdkit,nbdkit-no-sa
625
626           qemu-nbd
627               Use qemu-nbd.
628
629           qemu-nbd-no-sa
630               Use qemu-nbd, but disable socket activation.
631
632           nbdkit
633               Use nbdkit with the file plugin (see: nbdkit-file-plugin(1)).
634
635           nbdkit-no-sa
636               Use nbdkit, but disable socket activation
637
638           The "*-no-sa" variants allow virt-p2v to fall back to older
639           versions of qemu-nbd and nbdkit which did not support socket
640           activation.
641
642       --test-disk=/PATH/TO/DISK.IMG
643           For testing or debugging purposes, replace /dev/sda with a local
644           file.  You must use an absolute path.
645
646       -v
647       --verbose
648           In libguestfs ≥ 1.33.41, debugging is always enabled on the
649           conversion server, and this option does nothing.
650
651       -V
652       --version
653           Display version number and exit.
654

HOW VIRT-P2V WORKS

656       Note this section is not normative.  We may change how virt-p2v works
657       at any time in the future.
658
659       As described above, virt-p2v runs on a physical machine, interrogates
660       the user or the kernel command line for configuration, and then
661       establishes one or more ssh connections to the virt-v2v conversion
662       server.  The ssh connections are interactive shell sessions to the
663       remote host, but the commands sent are generated entirely by virt-p2v
664       itself, not by the user.  For data transfer, virt-p2v will use the
665       reverse port forward feature of ssh (ie. "ssh -R").
666
667       It will first make one or more test connections, which are used to
668       query the remote version of virt-v2v and its features.  The test
669       connections are closed before conversion begins.
670
671        ┌──────────────┐                      ┌─────────────────┐
672        │ virt-p2v     │                      │ virt-v2v        │
673        │ (physical    │  control connection  │ (conversion     │
674        │  server)   ╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍▶ server)       │
675        └──────────────┘                      └─────────────────┘
676
677       Once virt-p2v is ready to start conversion, it will open a single ssh
678       control connection.  It first sends a mkdir command to create a
679       temporary directory on the conversion server.  The directory name is
680       randomly chosen and is displayed in the GUI.  It has the form:
681
682        /tmp/virt-p2v-YYYYMMDD-XXXXXXXX
683
684       where "YYYYMMDD" is the current date, and the ‘X’s are random
685       characters.
686
687       Into this directory are written various files which include:
688
689       dmesg
690       lscpu
691       lspci
692       lsscsi
693       lsusb
694           (before conversion)
695
696           The output of the corresponding commands (ie dmesg(1), lscpu(1)
697           etc) on the physical machine.
698
699           The dmesg output is useful for detecting problems such as missing
700           device drivers or firmware on the virt-p2v ISO.  The others are
701           useful for debugging novel hardware configurations.
702
703       environment
704           (before conversion)
705
706           The content of the environment where virt-v2v(1) will run.
707
708       name
709           (before conversion)
710
711           The name (usually the hostname) of the physical machine.
712
713       physical.xml
714           (before conversion)
715
716           Libvirt XML describing the physical machine.  It is used to pass
717           data about the physical source host to virt-v2v(1) via the -i
718           libvirtxml option.
719
720           Note this is not "real" libvirt XML (and must never be loaded into
721           libvirt, which would reject it anyhow).  Also it is not the same as
722           the libvirt XML which virt-v2v generates in certain output modes.
723
724       p2v-version
725       v2v-version
726           (before conversion)
727
728           The versions of virt-p2v and virt-v2v respectively.
729
730       status
731           (after conversion)
732
733           The final status of the conversion.  0 if the conversion was
734           successful.  Non-zero if the conversion failed.
735
736       time
737           (before conversion)
738
739           The start date/time of conversion.
740
741       virt-v2v-conversion-log.txt
742           (during/after conversion)
743
744           The conversion log.  This is just the output of the virt-v2v
745           command on the conversion server.  If conversion fails, you should
746           examine this log file, and you may be asked to supply the complete,
747           unedited log file in any bug reports or support tickets.
748
749       virt-v2v-wrapper.sh
750           (before conversion)
751
752           This is the wrapper script which is used when running virt-v2v.
753           For interest only, do not attempt to run this script yourself.
754
755       Before conversion actually begins, virt-p2v then makes one or more
756       further ssh connections to the server for data transfer.
757
758       The transfer protocol used currently is NBD (Network Block Device),
759       which is proxied over ssh.  The NBD server is qemu-nbd(1) by default
760       but others can be selected using the --nbd command line option.
761
762       There is one ssh connection per physical hard disk on the source
763       machine (the common case — a single hard disk — is shown below):
764
765        ┌──────────────┐                      ┌─────────────────┐
766        │ virt-p2v     │                      │ virt-v2v        │
767        │ (physical    │  control connection  │ (conversion     │
768        │  server)   ╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍▶ server)       │
769        │              │                      │                 │
770        │              │  data connection     │                 │
771        │            ╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍▶               │
772        │qemu-nbd ← ─┘ │                      │└─ ← NBD         │
773        │/dev/sda      │                      │     requests    │
774        ∼              ∼                      ∼                 ∼
775        └──────────────┘                      └─────────────────┘
776
777       Although the ssh data connection is originated from the physical server
778       and terminates on the conversion server, in fact NBD requests flow in
779       the opposite direction.  This is because the reverse port forward
780       feature of ssh ("ssh -R") is used to open a port on the loopback
781       interface of the conversion server which is proxied back by ssh to the
782       NBD server running on the physical machine.  The effect is that
783       virt-v2v via libguestfs can open nbd connections which directly read
784       the hard disk(s) of the physical server.
785
786       Two layers of protection are used to ensure that there are no writes to
787       the hard disks: Firstly, the qemu-nbd -r (readonly) option is used.
788       Secondly libguestfs creates an overlay on top of the NBD connection
789       which stores writes in a temporary file on the conversion file.
790
791       The long "virt-v2v -i libvirtxml physical.xml ..." command is wrapped
792       inside a wrapper script and uploaded to the conversion server.  The
793       final step is to run this wrapper script, in turn running the virt-v2v
794       command.  The virt-v2v command references the physical.xml file (see
795       above), which in turn references the NBD listening port(s) of the data
796       connection(s).
797
798       Output from the virt-v2v command (messages, debugging etc) is saved
799       both in the log file on the conversion server.  Only informational
800       messages are sent back over the control connection to be displayed in
801       the graphical UI.
802

SEE ALSO

804       virt-p2v-make-disk(1), virt-p2v-make-kickstart(1),
805       virt-p2v-make-kiwi(1), virt-v2v(1), qemu-nbd(1), nbdkit(1),
806       nbdkit-file-plugin(1), ssh(1), sshd(8), sshd_config(5),
807       http://libguestfs.org/.
808

AUTHORS

810       Matthew Booth
811
812       John Eckersberg
813
814       Richard W.M. Jones http://people.redhat.com/~rjones/
815
816       Mike Latimer
817
818       Pino Toscano
819
820       Tingting Zheng
821
823       Copyright (C) 2009-2019 Red Hat Inc.
824

LICENSE

826       This program is free software; you can redistribute it and/or modify it
827       under the terms of the GNU General Public License as published by the
828       Free Software Foundation; either version 2 of the License, or (at your
829       option) any later version.
830
831       This program is distributed in the hope that it will be useful, but
832       WITHOUT ANY WARRANTY; without even the implied warranty of
833       MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
834       General Public License for more details.
835
836       You should have received a copy of the GNU General Public License along
837       with this program; if not, write to the Free Software Foundation, Inc.,
838       51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
839

BUGS

841       To get a list of bugs against libguestfs, use this link:
842       https://bugzilla.redhat.com/buglist.cgi?component=libguestfs&product=Virtualization+Tools
843
844       To report a new bug against libguestfs, use this link:
845       https://bugzilla.redhat.com/enter_bug.cgi?component=libguestfs&product=Virtualization+Tools
846
847       When reporting a bug, please supply:
848
849       ·   The version of libguestfs.
850
851       ·   Where you got libguestfs (eg. which Linux distro, compiled from
852           source, etc)
853
854       ·   Describe the bug accurately and give a way to reproduce it.
855
856       ·   Run libguestfs-test-tool(1) and paste the complete, unedited output
857           into the bug report.
858
859
860
861libguestfs-1.40.1                 2019-01-17                       virt-p2v(1)
Impressum