--- /dev/null
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>virt-p2v - P2V migration tool</title>
+<link rel="stylesheet" href="virt-p2v.1.css" type="text/css" />
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root@localhost" />
+</head>
+
+<body>
+
+<p><a name="__index__"></a></p>
+<!-- INDEX BEGIN -->
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#summary">SUMMARY</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#standard_usage">STANDARD USAGE</a></li>
+ <ul>
+
+ <li><a href="#booting_p2v_guest_on_virtualization_host">BOOTING P2V GUEST ON VIRTUALIZATION HOST</a></li>
+ </ul>
+
+ <li><a href="#getting_a_shell">GETTING A SHELL</a></li>
+ <ul>
+
+ <li><a href="#log_file">LOG FILE</a></li>
+ </ul>
+
+ <li><a href="#server_requirements">SERVER REQUIREMENTS</a></li>
+ <li><a href="#building_a_custom_live_cd">BUILDING A CUSTOM LIVE CD</a></li>
+ <ul>
+
+ <li><a href="#editing_defaults_in_the_virtp2v_script">EDITING DEFAULTS IN THE <code>virt-p2v</code> SCRIPT</a></li>
+ <li><a href="#iso_attachments">ISO ATTACHMENTS</a></li>
+ </ul>
+
+ <li><a href="#booting_from_a_usb_key_instead_of_a_cd">BOOTING FROM A USB KEY INSTEAD OF A CD</a></li>
+ <li><a href="#testing_an_iso_under_qemu_or_kvm">TESTING AN ISO UNDER QEMU OR KVM</a></li>
+ <li><a href="#see_also">SEE ALSO</a></li>
+ <li><a href="#authors">AUTHORS</a></li>
+ <li><a href="#copyright">COPYRIGHT</a></li>
+ <li><a href="#reporting_bugs">REPORTING BUGS</a></li>
+</ul>
+<!-- INDEX END -->
+
+<hr />
+<p>
+</p>
+<h1><a name="name">NAME</a></h1>
+<p>virt-p2v - P2V (physical to virtual machine) migration tool</p>
+<p>
+</p>
+<hr />
+<h1><a name="summary">SUMMARY</a></h1>
+<p>virt-p2v</p>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p>virt-p2v is a live CD for migrating physical machines to virtual
+machine guests.</p>
+<p>In the simplest mode of operation, you take a pre-built live CD ISO
+from the main website (<a href="http://et.redhat.com/~rjones/virt-p2v/">http://et.redhat.com/~rjones/virt-p2v/</a>) and
+burn it to a CD-R. Then insert the CD-R into the physical machine
+which must be migrated, reboot, and follow the on-screen instructions.
+See <strong>STANDARD USAGE</strong> section below.</p>
+<p>You may also build a customized live CD. Typically this will contain
+things like server details specific to your organization, so that the
+live CD can run mostly or completely automatically. See <strong>BUILDING A
+CUSTOM LIVE CD</strong> section below.</p>
+<p>In both cases, files and disk images are transferred from the physical
+machine over the network to the virtualization host machine over ssh.
+Therefore <code>sshd</code> must be running on the virtualization host, and must
+be accessible to that host. See <strong>SERVER REQUIREMENTS</strong> section below.</p>
+<p>The <code>virt-p2v</code> script must only be run from the live CD. It isn't
+designed to run outside this environment and could do Bad Things to
+your machine if you try it. The script contains some checks to try to
+stop you from doing this.</p>
+<p>Virt-p2v does not modify the physical machine, its disks,
+configuration etc.</p>
+<p>
+</p>
+<hr />
+<h1><a name="standard_usage">STANDARD USAGE</a></h1>
+<p>After booting the live CD-R, you are presented with a series of
+questions. This section explains each question.</p>
+<dl>
+<dt><strong><a name="item_remote_host">Remote host</a></strong>
+
+<dd>
+<p>Enter the name or IP address of the virtualization host. This is the
+host running Xen (or any other virtualization system supported by
+libvirt, eg. QEMU). This host should be accessible on the network and
+running an SSH daemon (<code>sshd</code>).</p>
+</dd>
+</li>
+<dt><strong><a name="item_remote_port">Remote port</a></strong>
+
+<dd>
+<p>This is the port name or number of the SSH server on the remote host.
+The default is <code>22</code> which is the standard SSH port.</p>
+</dd>
+</li>
+<dt><strong><a name="item_remote_directory">Remote directory</a></strong>
+
+<dd>
+<p>Enter the directory on the remote host where disk <code>image(s)</code> and
+configuration <code>file(s)</code> must reside.</p>
+</dd>
+<dd>
+<p>Note that if the remote host is running SELinux then you may not be
+able to start a Xen guest unless its disk <code>image(s)</code> are located in the
+default directory, <code>/var/lib/xen/images</code>.</p>
+</dd>
+</li>
+<dt><strong><a name="item_remote_username">Remote username</a></strong>
+
+<dd>
+<p>Enter the remote SSH username to use to log in to the remote host.</p>
+</dd>
+<dd>
+<p>If you use the default username of <code>root</code> then you should ensure that
+remote root logins are enabled on the remote host
+(ie. <code>PermitRootLogin yes</code> in <code>/etc/ssh/sshd_config</code>).</p>
+</dd>
+</li>
+<dt><strong><a name="item_network_configuration">Network configuration</a></strong>
+
+<dd>
+<p>Choose the way that the live CD configures network access. The
+current options are:</p>
+</dd>
+<dl>
+<dt><strong><a name="item_automatic_configuration">Automatic configuration</a></strong>
+
+<dd>
+<p>In this mode, the live CD attempts to reuse the network configuration
+from the physical machine's root filesystem. You should probably try
+this method even though occasionally it does not work.</p>
+</dd>
+</li>
+<dt><strong><a name="item_configure_from_the_shell">Configure from the shell</a></strong>
+
+<dd>
+<p>In this mode you will be dropped into a command shell and you will
+need to issue the correct sequence of <code>/sbin/ifconfig</code> commands in
+order to configure the network interface.</p>
+</dd>
+<dd>
+<p>A typical sequence of commands which should bring up the network
+interface would be:</p>
+</dd>
+<dd>
+<pre>
+ /sbin/ifconfig eth0 AA.BB.CC.DD
+ /sbin/route add default gw GG.HH.II.JJ eth0</pre>
+</dd>
+<dd>
+<p>where <code>AA.BB.CC.DD</code> is the IP address and <code>GG.HH.II.JJ</code> is the
+gateway.</p>
+</dd>
+</li>
+</dl>
+<dt><strong><a name="item_devices">Devices</a></strong>
+
+<dd>
+<p>This question lists out all local block devices (hard disk drives and
+similar) and asks you to choose which will be sent to the remote host.
+You must send at least one block device.</p>
+</dd>
+</li>
+<dt><strong><a name="item_root_device">Root device</a></strong>
+
+<dd>
+<p>This question lists out possible root filesystems and asks you to
+choose the right one. Choose the filesystem which would normally be
+mounted as <code>/</code> on the system.</p>
+</dd>
+<dd>
+<p>Virt-p2v performs some autodetection and is in most cases able to work
+out which filesystems are possible root filesystems. It displays what
+it thinks is on each filesystem, but leaves it up to the user to make
+a final decision.</p>
+</dd>
+<dd>
+<p>The root filesystem is critical because it contains <code>/etc/fstab</code>.
+This is used during P2V both to determine how other filesystems are
+normally mounted on the machine, and because this file and others
+under <code>/etc</code> may need to be modified during P2V conversion.</p>
+</dd>
+<dd>
+<p>If the machine has more than one root filesystem (typically because
+the machine is dual-booted with another operating system), then you
+must choose only one of them to perform the P2V conversion on.</p>
+</dd>
+</li>
+<dt><strong><a name="item_hypervisor">Hypervisor</a></strong>
+
+<dd>
+<p>This question asks you to choose the hypervisor / virtualization
+system in use on the remote host.</p>
+</dd>
+<dd>
+<p>If you select <em>Xen</em>, <em>QEMU</em> or <em>KVM</em> then virt-p2v will produce a
+configuration file which is customized for the selected system. If
+you select <em>Other</em> then virt-p2v will produce a generic configuration
+file which will probably require hand-modification to work.</p>
+</dd>
+<dd>
+<p>See also <a href="http://libvirt.org/format.html">http://libvirt.org/format.html</a>.</p>
+</dd>
+</li>
+<dt><strong><a name="item_machine_architecture">Machine architecture</a></strong>
+
+<dd>
+<p>This question asks you to choose the machine architecture. Virt-p2v
+can normally detect this, so you should leave it as <em>Auto-detect</em>.</p>
+</dd>
+</li>
+<dt><strong><a name="item_memory">Memory</a></strong>
+
+<dd>
+<p>This question asks you to choose the amount of memory (RAM) in
+megabytes assigned to the virtual machine.</p>
+</dd>
+<dd>
+<p>If the entry is left blank, then virt-p2v will try to autodetect how
+much RAM is present in the physical machine and use that, and this is
+probably a good choice for most simple migrations.</p>
+</dd>
+</li>
+<dt><strong><a name="item_virtual_cpus">Virtual CPUs</a></strong>
+
+<dd>
+<p>This question asks you to choose the number of virtual CPUs assigned
+to the virtual machine. Choosing <code>1</code> causes the virtual machine to
+be uniprocessor, and choosing some number greater than 1 causes the
+virtual machine to be SMP.</p>
+</dd>
+<dd>
+<p>If the entry is left blank, then virt-p2v will try to autodetect how
+many CPU cores are present in the physical machine and use that, and
+this is probably a good choice for most simple migrations.</p>
+</dd>
+</li>
+<dt><strong><a name="item_mac_address">MAC address</a></strong>
+
+<dd>
+<p>Here you should enter a MAC address for the virtual machine's emulated
+network card. MAC addresses are written as <code>aa:bb:cc:dd:ee:ff</code> where
+<code>aa</code>, <code>bb</code> etc are hexadecimal octets.</p>
+</dd>
+<dd>
+<p>Leaving it blank will cause virt-p2v to choose a random MAC address
+within the <code>00:16:3e:..</code> space reserved for Xen guests. These MAC
+addresses are not tested for uniqueness so there is a very small
+chance that they could coincide, which would leave a guest unable to
+access the virtual network.</p>
+</dd>
+</li>
+<dt><strong><a name="item_verify_and_proceed">Verify and proceed</a></strong>
+
+<dd>
+<p>In this step you are asked to verify the settings above. If any are
+incorrect, use the <em>Back</em> button to navigate back to the setting. If
+all settings are correct, use the <em>OK</em> button to begin the P2V
+conversion.</p>
+</dd>
+</li>
+<dt><strong><a name="item_network_autoconfiguration">Network autoconfiguration</a></strong>
+
+<dd>
+<p>If you selected network autoconfiguration above then virt-p2v tries to
+autoconfigure the network and ping the remote host. It then asks
+<em>Did automatic network configuration work?</em></p>
+</dd>
+<dd>
+<p>You should answer <code>y</code> here if it worked.</p>
+</dd>
+<dd>
+<p>Answering <code>n</code> will drop you into a command shell.</p>
+</dd>
+<dd>
+<p>You can also switch to another virtual console if you need to perform
+additional tests. See section <strong>GETTING A SHELL</strong> below.</p>
+</dd>
+</li>
+<dt><strong><a name="item_ssh_connection">SSH connection</a></strong>
+
+<dd>
+<p>Unless you have set up an SSH key, or the SSH server on the remote
+host allows passwordless logins, then for each file that has to be
+transferred to the remote host you will need to confirm the identity
+of the remote host and/or enter a password.</p>
+</dd>
+<dd>
+<p>To understand more about this, please see the <em>ssh(1)</em> manual page.</p>
+</dd>
+</li>
+</dl>
+<p>
+</p>
+<h2><a name="booting_p2v_guest_on_virtualization_host">BOOTING P2V GUEST ON VIRTUALIZATION HOST</a></h2>
+<p>Once the P2V conversion has been completed, and assuming it was
+successful, you will find a configuration file and one or more disk
+images on the remote host.</p>
+<p>The files will be located in the directory selected, usually
+<code>/var/lib/xen/images</code>. The names of the files are made up of:</p>
+<p><code>p2v-hostname-YYYYMMDDHHMM.conf</code> or
+<code>p2v-hostname-YYYYMMDDHHMM-hdX.img</code></p>
+<p>To simply start up the guest, use the following commands as root:</p>
+<pre>
+ virsh define p2v-foo-2008MMDDHHMM.conf
+ virsh start foo</pre>
+<p>For QEMU/KVM do:</p>
+<pre>
+ virsh -c qemu:///system define p2v-foo-2008MMDDHHMM.conf
+ virsh -c qemu:///system start foo</pre>
+<p>For other hypervisors you will need to edit the configuration file and
+read <a href="http://libvirt.org/uri.html">http://libvirt.org/uri.html</a>.</p>
+<p>
+</p>
+<hr />
+<h1><a name="getting_a_shell">GETTING A SHELL</a></h1>
+<p>During all stages of P2V questions and conversion you can get a root
+shell on the physical machine. Use <em>ALT</em> <em>F2</em> keys to switch to the
+second virtual console, then log in as <em>root</em> with no password.</p>
+<p>
+</p>
+<h2><a name="log_file">LOG FILE</a></h2>
+<p>Virt-p2v writes a detailed log file to <code>/tmp/virt-p2v.log</code>. (Note
+that this <code>/tmp</code> directory is a ramdisk on the live CD, not the same
+as the <code>/tmp</code> directory of the physical machine, and more importantly
+it disappears when the machine is rebooted).</p>
+<p>If you are reporting a bug, please always supply this file.</p>
+<p>
+</p>
+<hr />
+<h1><a name="server_requirements">SERVER REQUIREMENTS</a></h1>
+<p>The virtualization host (remote host) must be running an SSH daemon
+(<code>sshd</code>), accessible from the physical machine which is being
+migrated.</p>
+<p>Previous versions of virt-p2v could use a special virt-p2v server.
+However this capability has been removed since there was practically
+no benefit.</p>
+<p>
+</p>
+<hr />
+<h1><a name="building_a_custom_live_cd">BUILDING A CUSTOM LIVE CD</a></h1>
+<p>To build a custom live CD you must download the source for virt-p2v
+from <a href="http://et.redhat.com/~rjones/virt-p2v/">http://et.redhat.com/~rjones/virt-p2v/</a> or from the Mercurial
+source repository (see website for details).</p>
+<p>Please read the <code>README</code> file to find the dependencies which are all
+in Fedora &gt; 8 or EPEL &gt; 5.</p>
+<p>The steps to creating a custom live CD are:</p>
+<ol>
+<li><strong><a name="item_edit_virt_2dp2v_and_adjust_defaults">Edit <code>virt-p2v</code> and adjust defaults</a></strong>
+
+<p>Find the section ``TO MAKE A CUSTOM virt-p2v SCRIPT ...'' which is near
+to the top of this file. Edit the defaults in this section as
+detailed below.</p>
+</li>
+<li><strong><a name="item_virt_2dp2v__2d_2dtest_to_verify_your_changes"><code>virt-p2v --test</code> to verify your changes</a></strong>
+
+<p>This command should not print anything at all. If it prints any
+message, then you will need to fix the error by going back to the
+first step.</p>
+</li>
+<li><strong><a name="item_make_build_or_make_update_to_build_a_custom_live_c"><code>make build</code> or <code>make update</code> to build a custom live CD</a></strong>
+
+<p><code>make build</code> will create a complete ISO from scratch. <code>make update</code>
+can be used to build a ``quick'' developer ISO by updating an existing
+ISO image. See section <strong>ISO ATTACHMENTS</strong> below for more details.</p>
+</li>
+<li><strong><a name="item_burn_the_iso_to_a_cd_2dr_and_test">Burn the ISO to a CD-R and test</a></strong>
+
+</ol>
+<p>
+</p>
+<h2><a name="editing_defaults_in_the_virtp2v_script">EDITING DEFAULTS IN THE <code>virt-p2v</code> SCRIPT</a></h2>
+<p>For each default, setting it to <code>None</code> will ask the user. All of the
+defaults are set to <code>None</code> in the standard, uncustomized virt-p2v
+script, and so the standard script asks all the questions.</p>
+<p>You may edit <code>virt-p2v</code> and change the defaults, in which case the
+user will not be questioned. In this way you can make the script
+partially or fully automated.</p>
+<p><em>Note about OCaml code:</em> <code>None</code> and <code>Some foo</code> are similar to the
+concept of a NULL pointer versus non-NULL pointer in other languages.
+This a variant type defined as:</p>
+<p>type α option = None | Some of α</p>
+<dl>
+<dt><strong><a name="item_greeting"><code>greeting</code></a></strong>
+
+<dd>
+<p>If this is <code>true</code> then we wait for a keypress after boot and at a
+couple of other stages. If set to <code>false</code> then we try not to wait
+for any keypresses (so more automated live CDs are possible).</p>
+</dd>
+</li>
+<dt><strong><a name="item_remote_host"><code>remote_host</code></a></strong>
+
+<dd>
+<p>Set this to <code>Some "hostname"</code> or <code>Some "IP-address"</code> to
+provide the name of the remote host.</p>
+</dd>
+</li>
+<dt><strong><a name="item_remote_port"><code>remote_port</code></a></strong>
+
+<dd>
+<p>Set this to <code>Some port</code> (eg. <code>Some 22</code>) to provide the port number
+of the remote host's SSH daemon.</p>
+</dd>
+</li>
+<dt><strong><a name="item_remote_directory"><code>remote_directory</code></a></strong>
+
+<dd>
+<p>Set this to <code>Some "path"</code> (eg. <code>Some "/var/lib/xen/images"</code>) to
+provide the directory where we update P2V converted images and
+configuration files.</p>
+</dd>
+</li>
+<dt><strong><a name="item_remote_username"><code>remote_username</code></a></strong>
+
+<dd>
+<p>Set this to <code>Some "username"</code> (eg. <code>Some "root"</code>) to provide the SSH
+username to use on the remote system.</p>
+</dd>
+</li>
+<dt><strong><a name="item_devices_to_send"><code>devices_to_send</code></a></strong>
+
+<dd>
+<p>Set this to a list of block devices to send to the remote system.
+For example, <code>Some ["sda"; "sdb"]</code>.</p>
+</dd>
+</li>
+<dt><strong><a name="item_root_filesystem"><code>root_filesystem</code></a></strong>
+
+<dd>
+<p>Set this to the name of the root filesystem.</p>
+</dd>
+<dd>
+<p>For a disk partition (eg. <code>/dev/sda1</code>), use:</p>
+</dd>
+<dd>
+<pre>
+ Some (Part ("sda", "1"))</pre>
+</dd>
+<dd>
+<p>For a logical volume (eg. <code>/dev/VolGroup00/LogVol00</code>), use:</p>
+</dd>
+<dd>
+<pre>
+ Some (LV ("VolGroup00", "LogVol00"))</pre>
+</dd>
+</li>
+<dt><strong><a name="item_network"><code>network</code></a></strong>
+
+<dd>
+<p>Set this to the choice for network setup. Use either <code>Some Auto</code> or
+<code>Some Shell</code> for auto-configuration or shell (manual) configuration
+respectively.</p>
+</dd>
+</li>
+<dt><strong><a name="item_hypervisor"><code>hypervisor</code></a></strong>
+
+<dd>
+<p>Set this to the choice of hypervisor or virtualization system. The
+choices are: <code>Some Xen</code>, <code>Some QEMU</code> or <code>Some KVM</code>.</p>
+</dd>
+</li>
+<dt><strong><a name="item_architecture"><code>architecture</code></a></strong>
+
+<dd>
+<p>Set this to the architecture. The choices are:
+<code>Some I386</code> (i386 and up, 32 bit),
+<code>Some X86_64</code> (AMD and Intel x86-64, 64 bit),
+<code>Some IA64</code> (Intel IA64),
+<code>Some PPC</code> (PowerPC, 32 bit),
+<code>Some PPC64</code> (PowerPC, 64 bit),
+<code>Some SPARC</code> (Sun SPARC, 32 bit),
+<code>Some SPARC64</code> (Sun SPARC, 64 bit),
+<code>OtherArch "foo"</code> (a hypothetical architecture called <em>foo</em>), or
+<code>UnknownArch</code> to auto-detect the architecture.</p>
+</dd>
+</li>
+<dt><strong><a name="item_memory"><code>memory</code></a></strong>
+
+<dd>
+<p>Set this to the size of memory in megabytes, eg. <code>Some 256</code>. If you
+set this to <code>Some 0</code> then virt-p2v will try to autodetect the amount
+of RAM installed on the physical machine.</p>
+</dd>
+</li>
+<dt><strong><a name="item_vcpus"><code>vcpus</code></a></strong>
+
+<dd>
+<p>Set this to the number of virtual CPUs, eg. <code>Some 1</code>. If you set
+this to <code>Some 0</code> then virt-p2v will try to autodetect the number of
+CPU cores on the physical machine.</p>
+</dd>
+</li>
+<dt><strong><a name="item_mac_address"><code>mac_address</code></a></strong>
+
+<dd>
+<p>Set this to the MAC address for the virtual network card, eg. <code>Some
+"aa:bb:cc:dd:ee:ff"</code>. If you set this to <code>Some ""</code> then virt-p2v
+will choose a random MAC address within the <code>00:16:3e:..</code> space
+reserved for Xen guests. These MAC addresses are not tested for
+uniqueness so there is a very small chance that they could coincide,
+which would leave a guest unable to access the virtual network.</p>
+</dd>
+</li>
+</dl>
+<p>
+</p>
+<h2><a name="iso_attachments">ISO ATTACHMENTS</a></h2>
+<p>Rebuilding a custom ISO is time-consuming. You can make a ``quick''
+developer ISO by updating an existing ISO image with a new custom
+<code>virt-p2v</code> script. This is useful for testing purposes.</p>
+<p>From the source directory, assuming that you have downloaded or
+built an existing <code>virt-p2v-*.iso</code>, you can just do:</p>
+<pre>
+ make update</pre>
+<p>or the equivalent manual command:</p>
+<pre>
+ ./iso-attach virt-p2v-VERSION.iso virt-p2v</pre>
+<p>
+</p>
+<hr />
+<h1><a name="booting_from_a_usb_key_instead_of_a_cd">BOOTING FROM A USB KEY INSTEAD OF A CD</a></h1>
+<p>If you wish to boot from a USB keydrive, use the livecd-iso-to-disk
+tool:</p>
+<pre>
+ livecd-iso-to-disk virt-p2v-$VERSION.iso /dev/sdX1</pre>
+<p>(Replace /dev/sdX1 with the actual USB device).</p>
+<p>In my experience I also had to set up a suitable MBR:</p>
+<pre>
+ cat /usr/lib/syslinux/mbr.bin > /dev/sdX</pre>
+<p>
+</p>
+<hr />
+<h1><a name="testing_an_iso_under_qemu_or_kvm">TESTING AN ISO UNDER QEMU OR KVM</a></h1>
+<p>If you have a virtual guest running under QEMU or KVM then
+you can test the P2V conversion process on the guest.</p>
+<p>(Technically this is a V2V -- virtual to virtual -- conversion).</p>
+<p>From the source directory do:</p>
+<pre>
+ make boot HDA=qemuimage.img</pre>
+<p>where <code>qemuimage.img</code> is the name of the QEMU/KVM image.</p>
+<p>You can also supply an <code>HDB</code> parameter to specify a second disk.</p>
+<p>
+</p>
+<hr />
+<h1><a name="see_also">SEE ALSO</a></h1>
+<p><em>virsh(1)</em>,
+<a href="http://www.libvirt.org/ocaml/">http://www.libvirt.org/ocaml/</a>,
+<a href="http://www.libvirt.org/">http://www.libvirt.org/</a>,
+<a href="http://et.redhat.com/~rjones/">http://et.redhat.com/~rjones/</a>,
+<a href="http://caml.inria.fr/">http://caml.inria.fr/</a></p>
+<p>
+</p>
+<hr />
+<h1><a name="authors">AUTHORS</a></h1>
+<p>Richard W.M. Jones <rjones @ redhat . com></p>
+<p>
+</p>
+<hr />
+<h1><a name="copyright">COPYRIGHT</a></h1>
+<p>(C) Copyright 2007-2008 Red Hat Inc., Richard W.M. Jones
+<a href="http://libvirt.org/">http://libvirt.org/</a></p>
+<p>This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2 of the License, or
+(at your option) any later version.</p>
+<p>This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.</p>
+<p>You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.</p>
+<p>
+</p>
+<hr />
+<h1><a name="reporting_bugs">REPORTING BUGS</a></h1>
+<p>Bugs can be viewed on the Red Hat Bugzilla page:
+<a href="https://bugzilla.redhat.com/">https://bugzilla.redhat.com/</a>.</p>
+<p>If you find a bug in virt-p2v, please follow these steps to report it:</p>
+<ol>
+<li><strong><a name="item_check_for_existing_bug_reports">Check for existing bug reports</a></strong>
+
+<p>Go to <a href="https://bugzilla.redhat.com/">https://bugzilla.redhat.com/</a> and search for similar bugs.
+Someone may already have reported the same bug, and they may even
+have fixed it.</p>
+</li>
+<li><strong><a name="item_capture_debug_and_error_messages">Capture debug and error messages</a></strong>
+
+<p>At the point where you get the error or unexpected behaviour,
+go to the second virtual console (<em>ALT</em> <em>F2</em>) and look at
+the logfile <code>/tmp/virt-p2v.log</code>. Please make sure that
+this file is attached to your bug report.</p>
+</li>
+<li><strong><a name="item_get_version_of_virt_2dp2v">Get version of virt-p2v</a></strong>
+
+<p>The version is in the name of the ISO. If you have built a custom
+virt-p2v ISO, please describe any changes that you have made.</p>
+</li>
+<li><strong><a name="item_submit_a_bug_report_2e">Submit a bug report.</a></strong>
+
+<p>Go to <a href="https://bugzilla.redhat.com/">https://bugzilla.redhat.com/</a> and enter a new bug.
+Please describe the problem in as much detail as possible.</p>
+<p>Remember to include the version number (step 3) and to
+attach the log file (step 2).</p>
+</li>
+<li><strong><a name="item_assign_the_bug_to_rjones__40_redhat_2ecom">Assign the bug to rjones @ redhat.com</a></strong>
+
+<p>Assign or reassign the bug to <strong>rjones @ redhat.com</strong> (without the
+spaces). You can also send me an email with the bug number if you
+want a faster response.</p>
+</li>
+</ol>
+
+</body>
+
+</html>
git.annexia.org / virt-p2v.git / blobdiff