1VIRT-V2V.CONF(5) User Contributed Perl Documentation VIRT-V2V.CONF(5)
2
6 virt-v2v.conf - configuration file for virt-v2v
7
9 "virt-v2v.conf" describes:
10 · a set of target profiles which pre-define a set of output options.
12 · how to map virtual network interface connections when importing
14 them from another environment.
15 · software which can be installed by virt-v2v during the conversion
17 process.
18
20 The configuration file is an XML document whose root element is
21 <virt-v2v>.
22 Target Profiles
24 A target profile is used to group a set of configuration options
25 defining a specific destination for a conversion. A user can specify a
26 target profile in place of the equivalent command line options.
27 A target profile is defined by an element in virt-v2v.conf which is a
29 child of the top-level virt-v2v element. For example:
30 <profile name='kvm1'>
32 <method>libvirt</method>
33 <storage format='raw' allocation='sparse'>default</storage>
34 <network type='default'>
35 <network type='network' name='red'/>
36 </network>
37 <network type='bridge' name='xenbr1'>
38 <network type='network' name='green'/>
39 </network>
40 </profile>
41 A target profile is identified by its name attribute. Allowed elements
43 are:
44 method
46 The output method, equivalent to the -o command line option. This
47 element is required.
48 storage
50 The output storage location, equivalent to the -os command line
51 option. This element is required.
52 storage can optionally have format and allocation attributes. If
54 specified, these are equivalent to the -of and -oa command line
55 options respectively.
56 network
58 A set of network mappings specific to this profile. See "Mapping
59 network interface connections" for detail of the format of this
60 element.
61 Network mappings specified in the selected profile will be used in
63 preference to top-level network mappings. A specific, matching top-
64 level mapping will still be used in preference to a default
65 specified in a profile.
66 Mapping network interface connections
68 When importing a guest from a different machine and/or hypervisor, it
69 is likely that the name of the virtual interface its network devices
70 were connected to will change. For example, a typical Xen guest will be
71 connected to a bridge device called xenbrN. This bridge is created by
72 Xen and will not exist locally by default.
73 virt-v2v can change these on import to connect to an appropriate local
75 interface. The mapping is specified by the <network> element, which is
76 a child of the root element. The configuration can specify any number
77 of <network> elements. <network> has 2 attributes:
78 type
80 type can be:
81 bridge
83 A bridge to a host network interface.
84 network
86 A managed virtual network.
87 default
89 A type which will match any network if there is no specific
90 match.
91 For Xen and ESX guests the source type will typically be 'bridge'.
93 A configuration may only contain a single default mapping.
94 name
96 name specifies the name of the given network or bridge. A default
97 mapping does not have a name.
98 The mapping is specified by a nested <network> element.
100 The following example specifies that a guest interface which bridged to
102 'xenbr1' before conversion should be changed to connect to the local
103 bridge called 'br0'. Any other network interface should be changed to
104 connect to the local managed network called 'default':
105 <network type='bridge' name='xenbr1'>
107 <network type='bridge' name='br0'/>
108 </network>
109 <network type='default'>
111 <network type='network' name='default'/>
112 </network>
113 Specifying software to be installed
115 virt-v2v may have to install software in a guest during the conversion
116 process to ensure it boots. An example is replacing a Xen
117 paravirtualised kernel with a normal kernel. This software will be
118 specific to the guest operating system.
119 Capabilities
121 A capability describes the set of software required for a specific
123 goal, for example VirtIO support. A capability describes only direct
124 dependencies. Transitive dependencies will be resolved by the
125 installation method, for example yum or "Local Installation".
126 <capability> is a child of the root element. There can be any number of
128 <capability> elements. See "Searching" for a description of the
129 attributes of <capability> and how they are matched.
130 Dependencies are specified in the <dep> element, which has the
132 following attributes:
133 name
135 The symbolic name of a dependency. On an rpm-based system this will
136 be the package name. This attribute is required.
137 minversion
139 The minimum required version of the software. For rpm-based systems
140 this must be specified as [epoch:]version[-release]. This attribute
141 is required.
142 ifinstalled
144 A dependency must normally be installed if it is not present, or
145 upgraded if it present but too old. If ifinstalled is 'yes', the
146 dependency will be upgraded if is present but too old, but not
147 installed if it is not already present.
148 Local Installation
150 If it is not possible to install required software using the guest's
152 update agent, the software can be installed from the conversion host.
153 In this case, it must be specified in the <app> element. <app> is a
154 child of the root element. The configuration can specify any number of
155 <app> elements. See "Searching" for a description of the attribute of
156 <app> and how they are matched.
157 The <app> element must contain a <path> element, which specifies the
159 path to the software. It may also contain any number of <dep> elements,
160 which specify the names of additional applications which may need to be
161 installed. Each dependency will be resolved in the same way as its
162 parent, by looking for a match based on os, distro, major, minor and
163 arch.
164 virt-v2v will attempt to install dependencies first. A dependency will
166 only be installed if it is not already installed, or the installed
167 version is older than the specified version. On x86_64, virt-v2v will
168 additionally check if an i386 version need to by updated, but only if
169 any i386 version of the package is already installed.
170 Paths given in <path> must be absolute, unless there is a top level
172 <path-root> element. If it exists, all <path> elements will be relative
173 to <path-root>.
174 The following example specifies the location of 'kernel' for RHEL 5,
176 all minor versions, on i686:
177 <app os='linux' distro='rhel' major='5' arch='i686' name='kernel'>
179 <path>rhel/5/kernel-2.6.18-128.el5.i686.rpm</path>
180 <dep>ecryptfs-utils</dep>
181 <dep>lvm2</dep>
182 </app>
183 <app os='linux' distro='rhel' major='5' arch='i386' name='ecryptfs-utils'>
184 <path>rhel/5/ecryptfs-utils-56-8.el5.i386.rpm</path>
185 </app>
186 <app os='linux' distro='rhel' major='5' arch='i386' name='lvm2'>
187 <path>rhel/5/lvm2-2.02.40-6.el5.i386.rpm</path>
188 <dep>device-mapper</dep>
189 <dep>device-mapper-event</dep>
190 </app>
191 <path-root>/var/lib/virt-v2v/software</path-root>
193 The kernel can be found at
195 /var/lib/virt-v2v/software/rhel/5/kernel-2.6.18-128.el5.i686.rpm. It
196 has 2 direct dependencies: ecryptfs and lvm2. ecryptfs-utils has no
197 additional dependencies, but lvm2 has 2 further dependencies (not shown
198 for brevity). All dependencies will also be installed if they are not
199 present, or are too old. All dependency paths are also relative to
200 /var/lib/virt-v2v/software.
201 Searching
203 Both <capability> and <app> are matched in the same way, based on the
205 following attributes:
206 name
208 The symbolic name of the software virt-v2v is looking for. name is
209 a mandatory attribute.
210 os The name of the guest operating system, as returned by virt-
212 inspector. This will be a string, like 'linux' or 'windows'.
213 distro
215 When os='linux', this is the Linux distribution as returned by
216 virt-inspector. Possible values include 'rhel', 'debian'.
217 major
219 The major version name of the guest operating system, as returned
220 by virt-inspector.
221 minor
223 The minor version name of the guest operating system, as returned
224 by virt-inspector.
225 arch
227 The guest architecture, as returned by virt-inspector.
228 virt-v2v searches for an <app> or <capability> by symbolic name,
230 matching based on its additional attributes. If an attribute is missing
231 it will match any value. If multiple elements would match a given
232 search, virt-v2v will choose the most specific match. Specifically, it
233 searches in the following order:
234 · os, distro, major, minor, arch
236 · os, distro, major, minor
238 · os, distro, major, arch
240 · os, distro, major
242 · os, distro
244 · os
246 If virt-v2v doesn't find a match it will quit with an error describing
248 what it was looking for.
249 Installing custom software during conversion
251 The 'Red Hat' converter, which converts RHEL and Fedora guests,
252 includes a hook which allows custom software to be installed during
253 conversion. The user can define a capability with the name
254 'user-custom'. The dependencies of this capability will be installed
255 during conversion in the same way as the dependencies of other
256 capabilities.
257 It is recommended that custom configuration changes are added to
259 /etc/virt-v2v.conf rather than /var/lib/virt-v2v/virt-v2v.db.
260
262 Copyright (C) 2009-2012 Red Hat Inc.
263
265 Example virt-v2v.conf in the documentation directory, virt-v2v(1),
266 virt-inspector(1), <http://libguestfs.org/>
267perl v5.10.1 2013-06-12 VIRT-V2V.CONF(5)