.\" Automatically generated by Podwrapper::Man 1.40.2 (Pod::Simple 3.35)
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings.  \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
.\" nothing in troff, for use with C<>.
.tr \(*W-
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
.    ds -- \(*W-
.    ds PI pi
.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
.    ds L" ""
.    ds R" ""
.    ds C` ""
.    ds C' ""
'br\}
.el\{\
.    ds -- \|\(em\|
.    ds PI \(*p
.    ds L" ``
.    ds R" ''
.    ds C`
.    ds C'
'br\}
.\"
.\" Escape single quotes in literal strings from groff's Unicode transform.
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\"
.\" If the F register is >0, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
.\" entries marked with X<> in POD.  Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.\"
.\" Avoid warning from groff about undefined register 'F'.
.de IX
..
.nr rF 0
.if \n(.g .if rF .nr rF 1
.if (\n(rF:(\n(.g==0)) \{\
.    if \nF \{\
.        de IX
.        tm Index:\\$1\t\\n%\t"\\$2"
..
.        if !\nF==2 \{\
.            nr % 0
.            nr F 2
.        \}
.    \}
.\}
.rr rF
.\" ========================================================================
.\"
.IX Title "virt-p2v 1"
.TH virt-p2v 1 "2019-02-07" "libguestfs-1.40.2" "Virtualization Support"
.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.if n .ad l
.nh
.SH "名前"
.IX Header "名前"
virt\-p2v \- Convert a physical machine to use \s-1KVM\s0
.SH "書式"
.IX Header "書式"
.Vb 1
\& virt\-p2v
\&
\& virt\-p2v.iso
.Ve
.SH "説明"
.IX Header "説明"
Virt\-p2v converts a physical machine to run virtualized on \s-1KVM,\s0 managed by
libvirt, OpenStack, oVirt, Red Hat Virtualisation (\s-1RHV\s0), or one of the other
targets supported by \fBvirt\-v2v\fR\|(1).
.PP
Normally you don’t run the virt\-p2v program directly.  Instead you have to
boot the physical machine using the bootable CD-ROM, \s-1ISO\s0 or \s-1PXE\s0 image.  This
bootable image contains the virt\-p2v binary and runs it automatically.
Booting from a CD\-ROM/etc is required because the disks which are being
converted must be quiescent.  It is not safe to try to convert a running
physical machine where other programs may be modifying the disk content at
the same time.
.PP
This manual page documents running the virt\-p2v program.  To create the
bootable image you should look at \fBvirt\-p2v\-make\-disk\fR\|(1) or
\&\fBvirt\-p2v\-make\-kickstart\fR\|(1).
.SH "NETWORK SETUP"
.IX Header "NETWORK SETUP"
Virt\-p2v runs on the physical machine which you want to convert.  It has to
talk to another server called the \*(L"conversion server\*(R" which must have
\&\fBvirt\-v2v\fR\|(1) installed on it.  It always talks to the conversion server
over \s-1SSH:\s0
.PP
.Vb 5
\& ┌──────────────┐                  ┌─────────────────┐
\& │ virt\-p2v     │                  │ virt\-v2v        │
\& │ (physical    │  ssh connection  │ (conversion     │
\& │  server)   ╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍▶ server)       │
\& └──────────────┘                  └─────────────────┘
.Ve
.PP
The virt\-v2v program on the conversion server does the actual conversion
(physical to virtual, and virtual to virtual conversions are sufficiently
similar that we use the same program to do both).
.PP
The \s-1SSH\s0 connection is always initiated from the physical server.  All data
is transferred over the \s-1SSH\s0 connection.  In terms of firewall and network
configuration, you only need to ensure that the physical server has access
to a port (usually \s-1TCP\s0 port 22) on the conversion server.  Note that the
physical machine may reconnect several times during the conversion process.
.PP
The reverse port forwarding feature of ssh (ie. \f(CW\*(C`ssh \-R\*(C'\fR) is required by
virt\-p2v, and it will not work if this is disabled on the conversion
server.  (\f(CW\*(C`AllowTcpForwarding\*(C'\fR must be \f(CW\*(C`yes\*(C'\fR in the \fBsshd_config\fR\|(5) file
on the conversion server).
.PP
The scp (secure copy) feature of ssh is required by virt\-p2v so it can send
over small files (this is \fInot\fR the method by which disks are copied).
.PP
The conversion server does not need to be a physical machine.  It could be a
virtual machine, as long as it has sufficient memory and disk space to do
the conversion, and as long as the physical machine can connect directly to
its \s-1SSH\s0 port.  (See also \*(L"Resource requirements\*(R" in \fBvirt\-v2v\fR\|(1)).
.PP
Because all of the data on the physical server’s hard drive(s) has to be
copied over the network, the speed of conversion is largely determined by
the speed of the network between the two machines.
.SH "GUI INTERACTIVE CONFIGURATION"
.IX Header "GUI INTERACTIVE CONFIGURATION"
When you start virt\-p2v, you'll see a graphical configuration dialog that
walks you through connection to the conversion server, asks for the
password, which local hard disks you want to convert, and other things like
the name of the guest to create and the number of virtual CPUs to give it.
.SS "\s-1SSH CONFIGURATION DIALOG\s0"
.IX Subsection "SSH CONFIGURATION DIALOG"
When virt\-p2v starts up in \s-1GUI\s0 mode, the first dialog looks like this:
.PP
.Vb 11
\& ┌─────────────────────────────────────────────────────────────┐
\& │                           virt\-p2v                          │
\& │                                                             │
\& │ Conversion server: [_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_] : [22_\|_\|_] │
\& │                                                             │
\& │         User name: [root_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_] │
\& │                                                             │
\& │          Password: [_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_] │
\& │                                                             │
\& │  SSH Identity URL: [_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_] │
\& │                                                             │
.Ve
.PP
In the fields above, you must enter the details of the conversion server:
the hostname, \s-1SSH\s0 port number, remote user name, and either the password or
\&\s-1SSH\s0 identity (private key) \s-1URL.\s0  The conversion server must have an up to
date version of virt\-v2v.
.PP
Normally you must log in to the conversion server as root, but if you check
the following box:
.PP
.Vb 3
\& │                                                             │
\& │                    [ ] Use sudo when running virt\-v2v       │
\& │                                                             │
.Ve
.PP
then you can log in as another user, and virt\-p2v will use the \fBsudo\fR\|(8)
command to elevate privileges to root.  Note that sudo must not require a
password.
.PP
It is also possible to run virt\-v2v on the conversion server entirely as
non-root, but output modes may be limited.  Consult the \fBvirt\-v2v\fR\|(1)
manual page for details.
.PP
At the bottom of the dialog are these buttons:
.PP
.Vb 6
\& │                                                             │
\& │                     [ Test connection ]                     │
\& │                                                             │
\& │ [ Configure network ] [ XTerm ] [ About virt\-p2v ] [ Next ] │
\& │                                                             │
\& └─────────────────────────────────────────────────────────────┘
.Ve
.PP
You must press the \f(CW\*(C`Test connection\*(C'\fR button first to test the \s-1SSH\s0
connection to the conversion server.  If that is successful (ie. you have
supplied the correct server name, user name, password, etc., and a suitable
version of virt\-v2v is available remotely) then press the \f(CW\*(C`Next\*(C'\fR button to
move to the next dialog.
.PP
You can use the \f(CW\*(C`Configure network\*(C'\fR button if you need to assign a static
\&\s-1IP\s0 address to the physical machine, or use Wifi, bonding or other network
features.
.PP
The \f(CW\*(C`XTerm\*(C'\fR button opens a shell which can be used for diagnostics, manual
network configuration, and so on.
.SS "\s-1DISK AND NETWORK CONFIGURATION DIALOG\s0"
.IX Subsection "DISK AND NETWORK CONFIGURATION DIALOG"
The second configuration dialog lets you configure the details of
conversion, including what to convert and where to send the guest.
.PP
In the left hand column, starting at the top, the target properties let you
select the name of the guest (ie. after conversion) and how many virtual
CPUs and how much \s-1RAM\s0 to give it.  The defaults come from the physical
machine, and you can usually leave them unchanged:
.PP
.Vb 9
\& ┌─────────────────────────────────────── ─ ─ ─ ─
\& │ Target properties:
\& │
\& │        Name: [hostname_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_]
\& │
\& │     # vCPUs: [4_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_]
\& │
\& │ Memory (MB): [16384_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_]
\& │
.Ve
.PP
The second panel on the left controls the virt\-v2v output options.  To
understand these options it is a really good idea to read the \fBvirt\-v2v\fR\|(1)
manual page.  You can leave the options at the default to create a guest as
a disk image plus libvirt \s-1XML\s0 file located in \fI/var/tmp\fR on the conversion
host.  This is a good idea if you are a first-time virt\-p2v user.
.PP
.Vb 10
\& │
\& │ Virt\-v2v output options:
\& │
\& │          Output to (\-o): [local             ▼]
\& │
\& │      Output conn. (\-oc): [_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_]
\& │
\& │    Output storage (\-os): [/var/tmp_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_]
\& │
\& │     Output format (\-of): [_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_]
\& │
\& │ Output allocation (\-oa): [sparse            ▼]
\& │
.Ve
.PP
All output options and paths are relative to the conversion server (\fInot\fR
to the physical server).
.PP
Finally in the left hand column is an information box giving the version of
virt\-p2v (on the physical server) and virt\-v2v (on the conversion server).
You should supply this information when reporting bugs.
.PP
In the right hand column are three panels which control what hard disks,
removable media devices, and network interfaces, will be created in the
output guest.  Normally leaving these at the default settings is fine.
.PP
.Vb 11
\& ─ ─ ───────────────────────────────────────┐
\&     Fixed hard disks                       │
\&                                            │
\&     Convert  Device                        │
\&     [✔]      sda                           │
\&              1024G HITACHI                 │
\&              s/n 12345                     │
\&     [✔]      sdb                           │
\&              119G HITACHI                  │
\&              s/n 12346                     │
\&                                            │
.Ve
.PP
Normally you would want to convert all hard disks.  If you want virt\-p2v to
completely ignore a local hard disk, uncheck it.  The hard disk that
contains the operating system must be selected.  If a hard disk is part of a
\&\s-1RAID\s0 array or \s-1LVM\s0 volume group (\s-1VG\s0), then either all hard disks in that
array/VG must be selected, or none of them.
.PP
.Vb 6
\&                                            │
\&     Removable media                        │
\&                                            │
\&     Convert  Device                        │
\&     [✔]      sr0                           │
\&                                            │
.Ve
.PP
If the physical machine has \s-1CD\s0 or \s-1DVD\s0 drives, then you can use the Removable
media panel to create corresponding drives on the guest after conversion.
Note that any data CDs/DVDs which are mounted in the drives are \fInot\fR
copied over.
.PP
.Vb 7
\&                                            │
\&     Network interfaces                     │
\&                                            │
\&     Convert  Device Connect to ...         |
\&     [✔]      em1    [default_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_] │
\&     [ ]      wlp3s0 [default_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_] │
\&                                            │
.Ve
.PP
In the Network interfaces panel, select the network interfaces that should
be created in the guest after conversion.  You can also connect these to
target hypervisor networks (for further information about this feature, see
\&\*(L"Networks and bridges\*(R" in \fBvirt\-v2v\fR\|(1)).
.PP
On supported hardware, left-clicking on the device name (eg. \f(CW\*(C`em1\*(C'\fR)  causes
a light to start flashing on the physical interface, allowing the interface
to be identified by the operator.
.PP
When you are ready to begin the conversion, press the \f(CW\*(C`Start conversion\*(C'\fR
button:
.PP
.Vb 4
\&                                            │
\&             [ Back ]  [ Start conversion ] │
\&                                            │
\& ─ ─ ───────────────────────────────────────┘
.Ve
.SS "\s-1CONVERSION RUNNING DIALOG\s0"
.IX Subsection "CONVERSION RUNNING DIALOG"
When conversion is running you will see this dialog:
.PP
.Vb 10
\& ┌────────────────────────────────────────────────────────┐
\& │                      virt\-p2v                          │
\& │                                                        │
\& │  ┌──────────────────────────────────────────────────┐  │
\& │  │                                                 ▲│  │
\& │  │                                                  │  │
\& │  │                                                  │  │
\& ∼  ∼                                                  ∼  ∼
\& │  │                                                  │  │
\& │  │                                                  │  │
\& │  │                                                 ▼│  │
\& │  └──────────────────────────────────────────────────┘  │
\& │                                                        │
\& │ Log files ... to /tmp/virt\-p2v\-xxx                     │
\& │                                                        │
\& │ Doing conversion ...                                   │
\& │                                                        │
\& │                                 [ Cancel conversion ]  │
\& │                                                        │
\& └────────────────────────────────────────────────────────┘
.Ve
.PP
In the main scrolling area you will see messages from the virt\-v2v process.
.PP
Below the main area, virt\-p2v shows you the location of the directory on the
conversion server that contains log files and other debugging information.
Below that is the current status and a button for cancelling conversion.
.PP
Once conversion has finished, you should shut down the physical machine.  If
conversion is successful, you should never reboot it.
.SH "KERNEL COMMAND LINE CONFIGURATION"
.IX Header "KERNEL COMMAND LINE CONFIGURATION"
If you don’t want to configure things using the graphical \s-1UI,\s0 an alternative
is to configure through the kernel command line.  This is especially
convenient if you are converting a lot of physical machines which are booted
using \s-1PXE.\s0
.PP
Where exactly you set command line arguments depends on your \s-1PXE\s0
implementation, but for pxelinux you put them in the \f(CW\*(C`APPEND\*(C'\fR field in the
\&\fIpxelinux.cfg\fR file.  For example:
.PP
.Vb 6
\& DEFAULT p2v
\& TIMEOUT 20
\& PROMPT 0
\& LABEL p2v
\&   KERNEL vmlinuz0
\&   APPEND initrd=initrd0.img [....] p2v.server=conv.example.com p2v.password=secret p2v.o=libvirt
.Ve
.PP
You have to set some or all of the following command line arguments:
.IP "\fBp2v.remote.server=SERVER\fR" 4
.IX Item "p2v.remote.server=SERVER"
.PD 0
.IP "\fBp2v.server=SERVER\fR" 4
.IX Item "p2v.server=SERVER"
.PD
The name or \s-1IP\s0 address of the conversion server.
.Sp
This is always required if you are using the kernel configuration method.
If virt\-p2v does not find this on the kernel command line then it switches
to the \s-1GUI\s0 (interactive) configuration method.
.IP "\fBp2v.remote.port=PORT\fR" 4
.IX Item "p2v.remote.port=PORT"
.PD 0
.IP "\fBp2v.port=PORT\fR" 4
.IX Item "p2v.port=PORT"
.PD
The \s-1SSH\s0 port number on the conversion server (default: \f(CW22\fR).
.IP "\fBp2v.auth.username=USERNAME\fR" 4
.IX Item "p2v.auth.username=USERNAME"
.PD 0
.IP "\fBp2v.username=USERNAME\fR" 4
.IX Item "p2v.username=USERNAME"
.PD
The \s-1SSH\s0 username that we log in as on the conversion server (default:
\&\f(CW\*(C`root\*(C'\fR).
.IP "\fBp2v.auth.password=PASSWORD\fR" 4
.IX Item "p2v.auth.password=PASSWORD"
.PD 0
.IP "\fBp2v.password=PASSWORD\fR" 4
.IX Item "p2v.password=PASSWORD"
.PD
The \s-1SSH\s0 password that we use to log in to the conversion server.
.Sp
The default is to try with no password.  If this fails then virt\-p2v will
ask the user to type the password (probably several times during
conversion).
.Sp
This setting is ignored if \f(CW\*(C`p2v.auth.identity.url\*(C'\fR is present.
.IP "\fBp2v.auth.identity.url=URL\fR" 4
.IX Item "p2v.auth.identity.url=URL"
.PD 0
.IP "\fBp2v.identity=URL\fR" 4
.IX Item "p2v.identity=URL"
.PD
Provide a \s-1URL\s0 pointing to an \s-1SSH\s0 identity (private key) file.  The \s-1URL\s0 is
interpreted by \fBcurl\fR\|(1) so any \s-1URL\s0 that curl supports can be used here,
including \f(CW\*(C`https://\*(C'\fR and \f(CW\*(C`file://\*(C'\fR.  For more information on using \s-1SSH\s0
identities, see \*(L"\s-1SSH IDENTITIES\*(R"\s0 below.
.Sp
If \f(CW\*(C`p2v.auth.identity.url\*(C'\fR is present, it overrides \f(CW\*(C`p2v.auth.password\*(C'\fR.
There is no fallback.
.IP "\fBp2v.auth.sudo\fR" 4
.IX Item "p2v.auth.sudo"
.PD 0
.IP "\fBp2v.sudo\fR" 4
.IX Item "p2v.sudo"
.PD
Use \f(CW\*(C`p2v.sudo\*(C'\fR to tell virt\-p2v to use \fBsudo\fR\|(8) to gain root privileges
on the conversion server after logging in as a non-root user (default: do
not use sudo).
.IP "\fBp2v.guestname=GUESTNAME\fR" 4
.IX Item "p2v.guestname=GUESTNAME"
.PD 0
.IP "\fBp2v.name=GUESTNAME\fR" 4
.IX Item "p2v.name=GUESTNAME"
.PD
The name of the guest that is created.  The default is to try to derive a
name from the physical machine’s hostname (if possible) else use a randomly
generated name.
.IP "\fBp2v.vcpus=N\fR" 4
.IX Item "p2v.vcpus=N"
The number of virtual CPUs to give to the guest.  The default is to use the
same as the number of physical CPUs.
.IP "\fBp2v.memory=n(M|G)\fR" 4
.IX Item "p2v.memory=n(M|G)"
The size of the guest memory.  You must specify the unit such as megabytes
or gigabytes by using for example \f(CW\*(C`p2v.memory=1024M\*(C'\fR or \f(CW\*(C`p2v.memory=1G\*(C'\fR.
.Sp
The default is to use the same amount of \s-1RAM\s0 as on the physical machine.
.IP "\fBp2v.cpu.vendor=VENDOR\fR" 4
.IX Item "p2v.cpu.vendor=VENDOR"
The vCPU vendor, eg. \*(L"Intel\*(R" or \*(L"\s-1AMD\*(R".\s0  The default is to use the same \s-1CPU\s0
vendor as the physical machine.
.IP "\fBp2v.cpu.model=MODEL\fR" 4
.IX Item "p2v.cpu.model=MODEL"
The vCPU model, eg. \*(L"IvyBridge\*(R".  The default is to use the same \s-1CPU\s0 model
as the physical machine.
.IP "\fBp2v.cpu.sockets=N\fR" 4
.IX Item "p2v.cpu.sockets=N"
Number of vCPU sockets to use.  The default is to use the same as the
physical machine.
.IP "\fBp2v.cpu.cores=N\fR" 4
.IX Item "p2v.cpu.cores=N"
Number of vCPU cores to use.  The default is to use the same as the physical
machine.
.IP "\fBp2v.cpu.threads=N\fR" 4
.IX Item "p2v.cpu.threads=N"
Number of vCPU hyperthreads to use.  The default is to use the same as the
physical machine.
.IP "\fBp2v.cpu.acpi\fR" 4
.IX Item "p2v.cpu.acpi"
Whether to enable \s-1ACPI\s0 in the remote virtual machine.  The default is to use
the same as the physical machine.
.IP "\fBp2v.cpu.apic\fR" 4
.IX Item "p2v.cpu.apic"
Whether to enable \s-1APIC\s0 in the remote virtual machine.  The default is to use
the same as the physical machine.
.IP "\fBp2v.cpu.pae\fR" 4
.IX Item "p2v.cpu.pae"
Whether to enable \s-1PAE\s0 in the remote virtual machine.  The default is to use
the same as the physical machine.
.IP "\fBp2v.rtc.basis=(unknown|utc|localtime)\fR" 4
.IX Item "p2v.rtc.basis=(unknown|utc|localtime)"
Set the basis of the Real Time Clock in the virtual machine.  The default is
to try to detect this setting from the physical machine.
.IP "\fBp2v.rtc.offset=[+|\-]HOURS\fR" 4
.IX Item "p2v.rtc.offset=[+|-]HOURS"
The offset of the Real Time Clock from \s-1UTC.\s0  The default is to try to detect
this setting from the physical machine.
.IP "\fBp2v.disks=sda,sdb,...\fR" 4
.IX Item "p2v.disks=sda,sdb,..."
A list of physical hard disks to convert, for example:
.Sp
.Vb 1
\& p2v.disks=sda,sdc
.Ve
.Sp
The default is to convert all local hard disks that are found.
.IP "\fBp2v.removable=sra,srb,...\fR" 4
.IX Item "p2v.removable=sra,srb,..."
A list of removable media to convert.  The default is to create virtual
removable devices for every physical removable device found.  Note that the
content of removable media is never copied over.
.IP "\fBp2v.interfaces=em1,...\fR" 4
.IX Item "p2v.interfaces=em1,..."
A list of network interfaces to convert.  The default is to create virtual
network interfaces for every physical network interface found.
.IP "\fBp2v.network_map=interface:target,...\fR" 4
.IX Item "p2v.network_map=interface:target,..."
.PD 0
.IP "\fBp2v.network=interface:target,...\fR" 4
.IX Item "p2v.network=interface:target,..."
.PD
Controls how network interfaces are connected to virtual networks on the
target hypervisor.  The default is to connect all network interfaces to the
target \f(CW\*(C`default\*(C'\fR network.
.Sp
You give a comma-separated list of \f(CW\*(C`interface:target\*(C'\fR pairs, plus
optionally a default target.  For example:
.Sp
.Vb 1
\& p2v.network=em1:ovirtmgmt
.Ve
.Sp
maps interface \f(CW\*(C`em1\*(C'\fR to target network \f(CW\*(C`ovirtmgmt\*(C'\fR.
.Sp
.Vb 1
\& p2v.network=em1:ovirtmgmt,em2:management,other
.Ve
.Sp
maps interface \f(CW\*(C`em1\*(C'\fR to \f(CW\*(C`ovirtmgmt\*(C'\fR, and \f(CW\*(C`em2\*(C'\fR to \f(CW\*(C`management\*(C'\fR, and any
other interface that is found to \f(CW\*(C`other\*(C'\fR.
.IP "\fBp2v.output.type=(libvirt|local|...)\fR" 4
.IX Item "p2v.output.type=(libvirt|local|...)"
.PD 0
.IP "\fBp2v.o=(libvirt|local|...)\fR" 4
.IX Item "p2v.o=(libvirt|local|...)"
.PD
Set the output mode.  This is the same as the virt\-v2v \fI\-o\fR option.  See
\&\*(L"\s-1OPTIONS\*(R"\s0 in \fBvirt\-v2v\fR\|(1).
.Sp
If not specified, the default is \f(CW\*(C`local\*(C'\fR, and the converted guest is
written to \fI/var/tmp\fR.
.IP "\fBp2v.output.allocation=(none|sparse|preallocated)\fR" 4
.IX Item "p2v.output.allocation=(none|sparse|preallocated)"
.PD 0
.IP "\fBp2v.oa=(none|sparse|preallocated)\fR" 4
.IX Item "p2v.oa=(none|sparse|preallocated)"
.PD
Set the output allocation mode.  This is the same as the virt\-v2v \fI\-oa\fR
option.  See \*(L"\s-1OPTIONS\*(R"\s0 in \fBvirt\-v2v\fR\|(1).
.IP "\fBp2v.output.connection=URI\fR" 4
.IX Item "p2v.output.connection=URI"
.PD 0
.IP "\fBp2v.oc=URI\fR" 4
.IX Item "p2v.oc=URI"
.PD
Set the output connection libvirt \s-1URI.\s0  This is the same as the virt\-v2v
\&\fI\-oc\fR option.  See \*(L"\s-1OPTIONS\*(R"\s0 in \fBvirt\-v2v\fR\|(1) and
http://libvirt.org/uri.html
.IP "\fBp2v.output.format=(raw|qcow2|...)\fR" 4
.IX Item "p2v.output.format=(raw|qcow2|...)"
.PD 0
.IP "\fBp2v.of=(raw|qcow2|...)\fR" 4
.IX Item "p2v.of=(raw|qcow2|...)"
.PD
Set the output format.  This is the same as the virt\-v2v \fI\-of\fR option.  See
\&\*(L"\s-1OPTIONS\*(R"\s0 in \fBvirt\-v2v\fR\|(1).
.IP "\fBp2v.output.storage=STORAGE\fR" 4
.IX Item "p2v.output.storage=STORAGE"
.PD 0
.IP "\fBp2v.os=STORAGE\fR" 4
.IX Item "p2v.os=STORAGE"
.PD
Set the output storage.  This is the same as the virt\-v2v \fI\-os\fR option.
See \*(L"\s-1OPTIONS\*(R"\s0 in \fBvirt\-v2v\fR\|(1).
.Sp
If not specified, the default is \fI/var/tmp\fR (on the conversion server).
.IP "\fBp2v.pre=COMMAND\fR" 4
.IX Item "p2v.pre=COMMAND"
.PD 0
.ie n .IP "\fBp2v.pre=""\s-1COMMAND ARG ...""\s0\fR" 4
.el .IP "\fBp2v.pre=``\s-1COMMAND ARG ...''\s0\fR" 4
.IX Item "p2v.pre=COMMAND ARG ..."
.PD
Select a pre-conversion command to run.  Any command or script can be
specified here.  If the command contains spaces, you must quote the whole
command with double quotes.  The default is not to run any command.
.IP "\fBp2v.post=poweroff\fR" 4
.IX Item "p2v.post=poweroff"
.PD 0
.IP "\fBp2v.post=reboot\fR" 4
.IX Item "p2v.post=reboot"
.IP "\fBp2v.post=COMMAND\fR" 4
.IX Item "p2v.post=COMMAND"
.ie n .IP "\fBp2v.post=""\s-1COMMAND ARG ...""\s0\fR" 4
.el .IP "\fBp2v.post=``\s-1COMMAND ARG ...''\s0\fR" 4
.IX Item "p2v.post=COMMAND ARG ..."
.PD
Select a post-conversion command to run if conversion is successful.  This
can be any command or script.  If the command contains spaces, you must
quote the whole command with double quotes.
.Sp
\&\fIIf\fR virt\-p2v is running as root, \fIand\fR the command line was set from
\&\fI/proc/cmdline\fR (not \fI\-\-cmdline\fR), then the default is to run the
\&\fBpoweroff\fR\|(8) command.  Otherwise the default is not to run any command.
.IP "\fBp2v.fail=COMMAND\fR" 4
.IX Item "p2v.fail=COMMAND"
.PD 0
.ie n .IP "\fBp2v.fail=""\s-1COMMAND ARG ...""\s0\fR" 4
.el .IP "\fBp2v.fail=``\s-1COMMAND ARG ...''\s0\fR" 4
.IX Item "p2v.fail=COMMAND ARG ..."
.PD
Select a post-conversion command to run if conversion fails.  Any command or
script can be specified here.  If the command contains spaces, you must
quote the whole command with double quotes.  The default is not to run any
command.
.IP "\fBip=dhcp\fR" 4
.IX Item "ip=dhcp"
Use \s-1DHCP\s0 for configuring the network interface (this is the default).
.SH "SSH IDENTITIES"
.IX Header "SSH IDENTITIES"
As a somewhat more secure alternative to password authentication, you can
use an \s-1SSH\s0 identity (private key) for authentication.
.PP
First create a key pair.  It must have an empty passphrase:
.PP
.Vb 1
\& ssh\-keygen \-t rsa \-N \*(Aq\*(Aq \-f id_rsa
.Ve
.PP
This creates a private key (\f(CW\*(C`id_rsa\*(C'\fR) and a public key (\f(CW\*(C`id_rsa.pub\*(C'\fR)
pair.
.PP
The public key should be appended to the \f(CW\*(C`authorized_keys\*(C'\fR file on the
virt\-v2v conversion server (usually to \f(CW\*(C`/root/.ssh/authorized_keys\*(C'\fR).
.PP
For distributing the private key, there are four scenarios from least secure
to most secure:
.IP "1." 4
Not using \s-1SSH\s0 identities at all, ie. password authentication.
.Sp
Anyone who can sniff the \s-1PXE\s0 boot parameters from the network or observe the
password some other way can log in to the virt\-v2v conversion server.
.IP "2." 4
\&\s-1SSH\s0 identity embedded in the virt\-p2v \s-1ISO\s0 or disk image.  In the \s-1GUI,\s0 use:
.Sp
.Vb 3
\& │          Password: [    <leave this field blank>       ] │
\& │                                                          │
\& │  SSH Identity URL: [file:///var/tmp/id_rsa_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_\|_] │
.Ve
.Sp
or on the kernel command line:
.Sp
.Vb 1
\& p2v.identity=file:///var/tmp/id_rsa
.Ve
.Sp
The \s-1SSH\s0 private key can still be sniffed from the network if using standard
\&\s-1PXE.\s0
.IP "3." 4
\&\s-1SSH\s0 identity downloaded from a website.  In the \s-1GUI,\s0 use:
.Sp
.Vb 3
\& │          Password: [    <leave this field blank>       ] │
\& │                                                          │
\& │  SSH Identity URL: [https://internal.example.com/id_rsa] │
.Ve
.Sp
or on the kernel command line:
.Sp
.Vb 1
\& p2v.identity=https://internal.example.com/id_rsa
.Ve
.Sp
Anyone could still download the private key and use it to log in to the
virt\-v2v conversion server, but you could provide some extra security by
configuring the web server to only allow connections from P2V machines.
.Sp
Note that \fBssh\-keygen\fR\|(1) creates the \f(CW\*(C`id_rsa\*(C'\fR (private key) file with
mode 0600.  If you simply copy the file to a webserver, the webserver will
not serve it.  It will reply with \*(L"403 Forbidden\*(R" errors.  You will need to
change the mode of the file to make it publicly readable, for example by
using:
.Sp
.Vb 1
\& chmod 0644 id_rsa
.Ve
.IP "4." 4
\&\s-1SSH\s0 identity embedded in the virt\-p2v \s-1ISO\s0 or disk image (like 2.), \fIand\fR
use of secure \s-1PXE, PXE\s0 over separate physical network, or sneakernet to
distribute virt\-p2v to the physical machine.
.PP
Both \fBvirt\-p2v\-make\-disk\fR\|(1) and \fBvirt\-p2v\-make\-kickstart\fR\|(1) have the
same option \fI\-\-inject\-ssh\-identity\fR for injecting the private key into the
virt\-p2v disk image / \s-1ISO.\s0  See also the following manual sections:
.PP
\&\*(L"\s-1ADDING AN SSH IDENTITY\*(R"\s0 in \fBvirt\-p2v\-make\-disk\fR\|(1)
.PP
\&\*(L"\s-1ADDING AN SSH IDENTITY\*(R"\s0 in \fBvirt\-p2v\-make\-kickstart\fR\|(1)
.SH "一般的な問題"
.IX Header "一般的な問題"
.SS "Timeouts"
.IX Subsection "Timeouts"
As described below (see \*(L"\s-1HOW VIRT\-P2V WORKS\*(R"\s0) virt\-p2v makes several
long-lived ssh connections to the conversion server.  If these connections
time out then virt\-p2v will fail.
.PP
To test if a timeout might be causing problems, open an XTerm on the
virt\-p2v machine, \f(CW\*(C`ssh root@\f(CIconversion\-server\f(CW\*(C'\fR, and leave it for at
least an hour.  If the session disconnects without you doing anything, then
there is a timeout which you should turn off.
.PP
Timeouts happen because:
.ie n .IP """TIMEOUT"" or ""TMOUT"" environment variable" 4
.el .IP "\f(CWTIMEOUT\fR or \f(CWTMOUT\fR environment variable" 4
.IX Item "TIMEOUT or TMOUT environment variable"
Check if one of these environment variables is set in the root shell on the
conversion server.
.ie n .IP "sshd ""ClientAlive*"" setting" 4
.el .IP "sshd \f(CWClientAlive*\fR setting" 4
.IX Item "sshd ClientAlive* setting"
Check for \f(CW\*(C`ClientAlive*\*(C'\fR settings in \f(CW\*(C`/etc/ssh/sshd_config\*(C'\fR on the
conversion server.
.IP "Firewall or \s-1NAT\s0 settings" 4
.IX Item "Firewall or NAT settings"
Check if there is a firewall or \s-1NAT\s0 box between virt\-p2v and the conversion
server, and if this firewall drops idle connections after a too-short time.
.Sp
virt\-p2v ≥ 1.36 attempts to work around firewall timeouts by sending ssh
keepalive messages every 5 minutes.
.SH "オプション"
.IX Header "オプション"
.IP "\fB\-\-help\fR" 4
.IX Item "--help"
ヘルプを表示します。
.IP "\fB\-\-cmdline=CMDLINE\fR" 4
.IX Item "--cmdline=CMDLINE"
This is used for debugging. Instead of parsing the kernel command line from
\&\fI/proc/cmdline\fR, parse the string parameter \f(CW\*(C`CMDLINE\*(C'\fR.
.IP "\fB\-\-colors\fR" 4
.IX Item "--colors"
.PD 0
.IP "\fB\-\-colours\fR" 4
.IX Item "--colours"
.PD
Use \s-1ANSI\s0 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,
\&\s-1ANSI\s0 colour sequences are disabled unless you use this option.
.IP "\fB\-\-iso\fR" 4
.IX Item "--iso"
This flag is passed to virt\-p2v when it is launched inside the virt\-p2v \s-1ISO\s0
environment, ie. when it is running on a real physical machine (and thus not
when testing).  It enables various dangerous features such as the Shutdown
popup button.
.IP "\fB\-\-nbd=server[,server...]\fR" 4
.IX Item "--nbd=server[,server...]"
Select which \s-1NBD\s0 server is used.  By default the following servers are
checked and the first one found is used:
\&\fI\-\-nbd=qemu\-nbd,qemu\-nbd\-no\-sa,nbdkit,nbdkit\-no\-sa\fR
.RS 4
.IP "\fBqemu-nbd\fR" 4
.IX Item "qemu-nbd"
Use qemu-nbd.
.IP "\fBqemu-nbd-no-sa\fR" 4
.IX Item "qemu-nbd-no-sa"
Use qemu-nbd, but disable socket activation.
.IP "\fBnbdkit\fR" 4
.IX Item "nbdkit"
Use nbdkit with the file plugin (see: \fBnbdkit\-file\-plugin\fR\|(1)).
.IP "\fBnbdkit-no-sa\fR" 4
.IX Item "nbdkit-no-sa"
Use nbdkit, but disable socket activation
.RE
.RS 4
.Sp
The \f(CW\*(C`*\-no\-sa\*(C'\fR variants allow virt\-p2v to fall back to older versions of
qemu-nbd and nbdkit which did not support socket
activation.
.RE
.IP "\fB\-\-test\-disk=/PATH/TO/DISK.IMG\fR" 4
.IX Item "--test-disk=/PATH/TO/DISK.IMG"
For testing or debugging purposes, replace \fI/dev/sda\fR with a local file.
You must use an absolute path.
.IP "\fB\-v\fR" 4
.IX Item "-v"
.PD 0
.IP "\fB\-\-verbose\fR" 4
.IX Item "--verbose"
.PD
In libguestfs ≥ 1.33.41, debugging is always enabled on the conversion
server, and this option does nothing.
.IP "\fB\-V\fR" 4
.IX Item "-V"
.PD 0
.IP "\fB\-\-version\fR" 4
.IX Item "--version"
.PD
バージョン番号を表示して、終了します。
.SH "HOW VIRT\-P2V WORKS"
.IX Header "HOW VIRT-P2V WORKS"
\&\fBNote this section is not normative.\fR We may change how virt\-p2v works at
any time in the future.
.PP
As described above, virt\-p2v runs on a physical machine, interrogates the
user or the kernel command line for configuration, and then establishes one
or more ssh connections to the virt\-v2v conversion server.  The ssh
connections are interactive shell sessions to the remote host, but the
commands sent are generated entirely by virt\-p2v itself, not by the user.
For data transfer, virt\-p2v will use the reverse port forward feature of ssh
(ie. \f(CW\*(C`ssh \-R\*(C'\fR).
.PP
It will first make one or more test connections, which are used to query the
remote version of virt\-v2v and its features.  The test connections are
closed before conversion begins.
.PP
.Vb 5
\& ┌──────────────┐                      ┌─────────────────┐
\& │ virt\-p2v     │                      │ virt\-v2v        │
\& │ (physical    │  control connection  │ (conversion     │
\& │  server)   ╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍▶ server)       │
\& └──────────────┘                      └─────────────────┘
.Ve
.PP
Once virt\-p2v is ready to start conversion, it will open a single ssh
control connection.  It first sends a mkdir command to create a temporary
directory on the conversion server.  The directory name is randomly chosen
and is displayed in the \s-1GUI.\s0  It has the form:
.PP
.Vb 1
\& /tmp/virt\-p2v\-YYYYMMDD\-XXXXXXXX
.Ve
.PP
where \f(CW\*(C`YYYYMMDD\*(C'\fR is the current date, and the ‘X’s are random characters.
.PP
Into this directory are written various files which include:
.IP "\fIdmesg\fR" 4
.IX Item "dmesg"
.PD 0
.IP "\fIlscpu\fR" 4
.IX Item "lscpu"
.IP "\fIlspci\fR" 4
.IX Item "lspci"
.IP "\fIlsscsi\fR" 4
.IX Item "lsscsi"
.IP "\fIlsusb\fR" 4
.IX Item "lsusb"
.PD
\&\fI(before conversion)\fR
.Sp
The output of the corresponding commands (ie \fBdmesg\fR\|(1), \fBlscpu\fR\|(1) etc)
on the physical machine.
.Sp
The dmesg output is useful for detecting problems such as missing device
drivers or firmware on the virt\-p2v \s-1ISO.\s0  The others are useful for
debugging novel hardware configurations.
.IP "\fIenvironment\fR" 4
.IX Item "environment"
\&\fI(before conversion)\fR
.Sp
The content of the environment where \fBvirt\-v2v\fR\|(1) will run.
.IP "\fIname\fR" 4
.IX Item "name"
\&\fI(before conversion)\fR
.Sp
The name (usually the hostname) of the physical machine.
.IP "\fIphysical.xml\fR" 4
.IX Item "physical.xml"
\&\fI(before conversion)\fR
.Sp
Libvirt \s-1XML\s0 describing the physical machine.  It is used to pass data about
the physical source host to \fBvirt\-v2v\fR\|(1) via the \fI\-i libvirtxml\fR option.
.Sp
Note this is not \*(L"real\*(R" libvirt \s-1XML\s0 (and must \fBnever\fR be loaded into
libvirt, which would reject it anyhow).  Also it is not the same as the
libvirt \s-1XML\s0 which virt\-v2v generates in certain output modes.
.IP "\fIp2v\-version\fR" 4
.IX Item "p2v-version"
.PD 0
.IP "\fIv2v\-version\fR" 4
.IX Item "v2v-version"
.PD
\&\fI(before conversion)\fR
.Sp
The versions of virt\-p2v and virt\-v2v respectively.
.IP "\fIstatus\fR" 4
.IX Item "status"
\&\fI(after conversion)\fR
.Sp
The final status of the conversion.  \f(CW0\fR if the conversion was successful.
Non-zero if the conversion failed.
.IP "\fItime\fR" 4
.IX Item "time"
\&\fI(before conversion)\fR
.Sp
The start date/time of conversion.
.IP "\fIvirt\-v2v\-conversion\-log.txt\fR" 4
.IX Item "virt-v2v-conversion-log.txt"
\&\fI(during/after conversion)\fR
.Sp
The conversion log.  This is just the output of the virt\-v2v command on the
conversion server.  If conversion fails, you should examine this log file,
and you may be asked to supply the \fBcomplete\fR, \fBunedited\fR log file in any
bug reports or support tickets.
.IP "\fIvirt\-v2v\-wrapper.sh\fR" 4
.IX Item "virt-v2v-wrapper.sh"
\&\fI(before conversion)\fR
.Sp
This is the wrapper script which is used when running virt\-v2v.  For
interest only, do not attempt to run this script yourself.
.PP
Before conversion actually begins, virt\-p2v then makes one or more further
ssh connections to the server for data transfer.
.PP
The transfer protocol used currently is \s-1NBD\s0 (Network Block Device), which is
proxied over ssh.  The \s-1NBD\s0 server is \fBqemu\-nbd\fR\|(1) by default but others
can be selected using the \fI\-\-nbd\fR command line option.
.PP
There is one ssh connection per physical hard disk on the source machine
(the common case — a single hard disk — is shown below):
.PP
.Vb 11
\& ┌──────────────┐                      ┌─────────────────┐
\& │ virt\-p2v     │                      │ virt\-v2v        │
\& │ (physical    │  control connection  │ (conversion     │
\& │  server)   ╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍▶ server)       │
\& │              │                      │                 │
\& │              │  data connection     │                 │
\& │            ╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍▶               │
\& │qemu\-nbd ← ─┘ │                      │└─ ← NBD         │
\& │/dev/sda      │                      │     requests    │
\& ∼              ∼                      ∼                 ∼
\& └──────────────┘                      └─────────────────┘
.Ve
.PP
Although the ssh data connection is originated from the physical server and
terminates on the conversion server, in fact \s-1NBD\s0 requests flow in the
opposite direction.  This is because the reverse port forward feature of ssh
(\f(CW\*(C`ssh \-R\*(C'\fR) is used to open a port on the loopback interface of the
conversion server which is proxied back by ssh to the \s-1NBD\s0 server running on
the physical machine.  The effect is that virt\-v2v via libguestfs can open
nbd connections which directly read the hard disk(s) of the physical server.
.PP
Two layers of protection are used to ensure that there are no writes to the
hard disks: Firstly, the qemu-nbd \fI\-r\fR (readonly) option is used.  Secondly
libguestfs creates an overlay on top of the \s-1NBD\s0 connection which stores
writes in a temporary file on the conversion file.
.PP
The long \f(CW\*(C`virt\-v2v \-i libvirtxml physical.xml ...\*(C'\fR command is wrapped
inside a wrapper script and uploaded to the conversion server.  The final
step is to run this wrapper script, in turn running the virt\-v2v command.
The virt\-v2v command references the \fIphysical.xml\fR file (see above), which
in turn references the \s-1NBD\s0 listening port(s)  of the data connection(s).
.PP
Output from the virt\-v2v command (messages, debugging etc) is saved both in
the log file on the conversion server.  Only informational messages are sent
back over the control connection to be displayed in the graphical \s-1UI.\s0
.SH "関連項目"
.IX Header "関連項目"
\&\fBvirt\-p2v\-make\-disk\fR\|(1), \fBvirt\-p2v\-make\-kickstart\fR\|(1),
\&\fBvirt\-p2v\-make\-kiwi\fR\|(1), \fBvirt\-v2v\fR\|(1), \fBqemu\-nbd\fR\|(1), \fBnbdkit\fR\|(1),
\&\fBnbdkit\-file\-plugin\fR\|(1), \fBssh\fR\|(1), \fBsshd\fR\|(8), \fBsshd_config\fR\|(5),
http://libguestfs.org/.
.SH "著者"
.IX Header "著者"
Matthew Booth
.PP
John Eckersberg
.PP
Richard W.M. Jones http://people.redhat.com/~rjones/
.PP
Mike Latimer
.PP
Pino Toscano
.PP
Tingting Zheng
.SH "COPYRIGHT"
.IX Header "COPYRIGHT"
Copyright (C) 2009\-2019 Red Hat Inc.
.SH "LICENSE"
.IX Header "LICENSE"
This program is free software; you can redistribute it and/or modify it
under the terms of the \s-1GNU\s0 General Public License as published by the
Free Software Foundation; either version 2 of the License, or (at your
option) any later version.
.PP
This program is distributed in the hope that it will be useful, but
\&\s-1WITHOUT ANY WARRANTY\s0; without even the implied warranty of
\&\s-1MERCHANTABILITY\s0 or \s-1FITNESS FOR A PARTICULAR PURPOSE.\s0  See the \s-1GNU\s0
General Public License for more details.
.PP
You should have received a copy of the \s-1GNU\s0 General Public License along
with this program; if not, write to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, \s-1MA 02110\-1301 USA.\s0
.SH "BUGS"
.IX Header "BUGS"
To get a list of bugs against libguestfs, use this link:
https://bugzilla.redhat.com/buglist.cgi?component=libguestfs&product=Virtualization+Tools
.PP
To report a new bug against libguestfs, use this link:
https://bugzilla.redhat.com/enter_bug.cgi?component=libguestfs&product=Virtualization+Tools
.PP
When reporting a bug, please supply:
.IP "\(bu" 4
The version of libguestfs.
.IP "\(bu" 4
Where you got libguestfs (eg. which Linux distro, compiled from source, etc)
.IP "\(bu" 4
Describe the bug accurately and give a way to reproduce it.
.IP "\(bu" 4
Run \fBlibguestfs\-test\-tool\fR\|(1) and paste the \fBcomplete, unedited\fR
output into the bug report.