1virt-p2v(1) Virtualization Support virt-p2v(1)
2
6 virt-p2v - Convert a physical machine to use KVM
7
9 virt-p2v
10 virt-p2v.iso
12
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 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 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
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 ┌──────────────┐ ┌─────────────────┐
37 │ virt-p2v │ │ virt-v2v │
38 │ (physical │ ssh connection │ (conversion │
39 │ server) ╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍▶ server) │
40 └──────────────┘ └─────────────────┘
41 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 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 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 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 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 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
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 SSH CONFIGURATION DIALOG
80 When virt-p2v starts up in GUI mode, the first dialog looks like this:
81 ┌─────────────────────────────────────────────────────────────┐
83 │ virt-p2v │
84 │ │
85 │ Conversion server: [____________________________] : [22___] │
86 │ │
87 │ User name: [root__________________________________] │
88 │ │
89 │ Password: [______________________________________] │
90 │ │
91 │ SSH Identity URL: [______________________________________] │
92 │ │
93 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 Normally you must log in to the conversion server as root, but if you
100 check the following box:
101 │ │
103 │ [ ] Use sudo when running virt-v2v │
104 │ │
105 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 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 At the bottom of the dialog are these buttons:
115 │ │
117 │ [ Test connection ] │
118 │ │
119 │ [ Configure network ] [ XTerm ] [ About virt-p2v ] [ Next ] │
120 │ │
121 └─────────────────────────────────────────────────────────────┘
122 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 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 The "XTerm" button opens a shell which can be used for diagnostics,
134 manual network configuration, and so on.
135 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 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 ┌─────────────────────────────────────── ─ ─ ─ ─
146 │ Target properties:
147 │
148 │ Name: [hostname______________]
149 │
150 │ # vCPUs: [4_____________________]
151 │
152 │ Memory (MB): [16384_________________]
153 │
154 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 │
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 All output options and paths are relative to the conversion server (not
177 to the physical server).
178 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 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 ─ ─ ───────────────────────────────────────┐
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 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 │
208 Removable media │
209 │
210 Convert Device │
211 [✔] sr0 │
212 │
213 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 │
220 Network interfaces │
221 │
222 Convert Device Connect to ... |
223 [✔] em1 [default_____________] │
224 [ ] wlp3s0 [default_____________] │
225 │
226 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 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 When you are ready to begin the conversion, press the "Start
237 conversion" button:
238 │
240 [ Back ] [ Start conversion ] │
241 │
242 ─ ─ ───────────────────────────────────────┘
243 CONVERSION RUNNING DIALOG
245 When conversion is running you will see this dialog:
246 ┌────────────────────────────────────────────────────────┐
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 In the main scrolling area you will see messages from the virt-v2v
269 process.
270 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 Once conversion has finished, you should shut down the physical
277 machine. If conversion is successful, you should never reboot it.
278
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 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 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 You have to set some or all of the following command line arguments:
297 p2v.remote.server=SERVER
299 p2v.server=SERVER
300 The name or IP address of the conversion server.
301 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 p2v.remote.port=PORT
307 p2v.port=PORT
308 The SSH port number on the conversion server (default: 22).
309 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 p2v.auth.password=PASSWORD
316 p2v.password=PASSWORD
317 The SSH password that we use to log in to the conversion server.
318 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 This setting is ignored if "p2v.auth.identity.url" is present.
324 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 If "p2v.auth.identity.url" is present, it overrides
333 "p2v.auth.password". There is no fallback.
334 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 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 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 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 The default is to use the same amount of RAM as on the physical
357 machine.
358 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 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 p2v.cpu.sockets=N
368 Number of vCPU sockets to use. The default is to use the same as
369 the physical machine.
370 p2v.cpu.cores=N
372 Number of vCPU cores to use. The default is to use the same as the
373 physical machine.
374 p2v.cpu.threads=N
376 Number of vCPU hyperthreads to use. The default is to use the same
377 as the physical machine.
378 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 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 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 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 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 p2v.disks=sda,sdb,...
400 A list of physical hard disks to convert, for example:
401 p2v.disks=sda,sdc
403 The default is to convert all local hard disks that are found.
405 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 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 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 You give a comma-separated list of "interface:target" pairs, plus
424 optionally a default target. For example:
425 p2v.network=em1:ovirtmgmt
427 maps interface "em1" to target network "ovirtmgmt".
429 p2v.network=em1:ovirtmgmt,em2:management,other
431 maps interface "em1" to "ovirtmgmt", and "em2" to "management", and
433 any other interface that is found to "other".
434 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 If not specified, the default is "local", and the converted guest
441 is written to /var/tmp.
442 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 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 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 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 If not specified, the default is /var/tmp (on the conversion
465 server).
466 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 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 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 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 ip=dhcp
496 Use DHCP for configuring the network interface (this is the
497 default).
498
500 As a somewhat more secure alternative to password authentication, you
501 can use an SSH identity (private key) for authentication.
502 First create a key pair. It must have an empty passphrase:
504 ssh-keygen -t rsa -N '' -f id_rsa
506 This creates a private key ("id_rsa") and a public key ("id_rsa.pub")
508 pair.
509 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 For distributing the private key, there are four scenarios from least
514 secure to most secure:
515 1. Not using SSH identities at all, ie. password authentication.
517 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 2. SSH identity embedded in the virt-p2v ISO or disk image. In the
523 GUI, use:
524 │ Password: [ <leave this field blank> ] │
526 │ │
527 │ SSH Identity URL: [file:///var/tmp/id_rsa_____________] │
528 or on the kernel command line:
530 p2v.identity=file:///var/tmp/id_rsa
532 The SSH private key can still be sniffed from the network if using
534 standard PXE.
535 3. SSH identity downloaded from a website. In the GUI, use:
537 │ Password: [ <leave this field blank> ] │
539 │ │
540 │ SSH Identity URL: [https://internal.example.com/id_rsa] │
541 or on the kernel command line:
543 p2v.identity=https://internal.example.com/id_rsa
545 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 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 chmod 0644 id_rsa
558 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 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 "ADDING AN SSH IDENTITY" in virt-p2v-make-disk(1)
568 "ADDING AN SSH IDENTITY" in virt-p2v-make-kickstart(1)
570
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 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 Timeouts happen because:
583 "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 sshd "ClientAlive*" setting
589 Check for "ClientAlive*" settings in "/etc/ssh/sshd_config" on the
590 conversion server.
591 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 virt-p2v ≥ 1.36 attempts to work around firewall timeouts by
598 sending ssh keepalive messages every 5 minutes.
599
601 --help
602 Display help.
603 --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 --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 --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 --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 qemu-nbd
627 Use qemu-nbd.
628 qemu-nbd-no-sa
630 Use qemu-nbd, but disable socket activation.
631 nbdkit
633 Use nbdkit with the file plugin (see: nbdkit-file-plugin(1)).
634 nbdkit-no-sa
636 Use nbdkit, but disable socket activation
637 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 --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 -v
647 --verbose
648 In libguestfs ≥ 1.33.41, debugging is always enabled on the
649 conversion server, and this option does nothing.
650 -V
652 --version
653 Display version number and exit.
654
656 Note this section is not normative. We may change how virt-p2v works
657 at any time in the future.
658 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 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 ┌──────────────┐ ┌─────────────────┐
672 │ virt-p2v │ │ virt-v2v │
673 │ (physical │ control connection │ (conversion │
674 │ server) ╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍▶ server) │
675 └──────────────┘ └─────────────────┘
676 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 /tmp/virt-p2v-YYYYMMDD-XXXXXXXX
683 where "YYYYMMDD" is the current date, and the ‘X’s are random
685 characters.
686 Into this directory are written various files which include:
688 dmesg
690 lscpu
691 lspci
692 lsscsi
693 lsusb
694 (before conversion)
695 The output of the corresponding commands (ie dmesg(1), lscpu(1)
697 etc) on the physical machine.
698 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 environment
704 (before conversion)
705 The content of the environment where virt-v2v(1) will run.
707 name
709 (before conversion)
710 The name (usually the hostname) of the physical machine.
712 physical.xml
714 (before conversion)
715 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 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 p2v-version
725 v2v-version
726 (before conversion)
727 The versions of virt-p2v and virt-v2v respectively.
729 status
731 (after conversion)
732 The final status of the conversion. 0 if the conversion was
734 successful. Non-zero if the conversion failed.
735 time
737 (before conversion)
738 The start date/time of conversion.
740 virt-v2v-conversion-log.txt
742 (during/after conversion)
743 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 virt-v2v-wrapper.sh
750 (before conversion)
751 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 Before conversion actually begins, virt-p2v then makes one or more
756 further ssh connections to the server for data transfer.
757 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 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 ┌──────────────┐ ┌─────────────────┐
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 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 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 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 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
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
810 Matthew Booth
811 John Eckersberg
813 Richard W.M. Jones http://people.redhat.com/~rjones/
815 Mike Latimer
817 Pino Toscano
819 Tingting Zheng
821
823 Copyright (C) 2009-2019 Red Hat Inc.
824
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 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 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
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 To report a new bug against libguestfs, use this link:
845 https://bugzilla.redhat.com/enter_bug.cgi?component=libguestfs&product=Virtualization+Tools
846 When reporting a bug, please supply:
848 · The version of libguestfs.
850 · Where you got libguestfs (eg. which Linux distro, compiled from
852 source, etc)
853 · Describe the bug accurately and give a way to reproduce it.
855 · Run libguestfs-test-tool(1) and paste the complete, unedited output
857 into the bug report.
858libguestfs-1.40.1 2019-01-17 virt-p2v(1)