virt-v2v-in-place(1)

πŸ’– NAME πŸ’–

virt-v2v-in-place β€” bestie, this one converts a guest to use KVM in place. Like, right where it's sitting. No moving boxes, no U-Haul. ✨


🌸 SYNOPSIS 🌸

 virt-v2v-in-place -i disk [other -i* options]
                   [virt-customize options]
                   filename
                   [-O output.xml]

 virt-v2v-in-place -i libvirt|libvirtxml [other -i* options]
                   [virt-customize options]
                   guest
                   [-O output.xml]

πŸ¦‹ DESCRIPTION πŸ¦‹

Virt-v2v-in-place takes one single guest from a foreign hypervisor and makes it run on KVM. And the way it does that?? in place. It literally modifies the original disk. Not a copy, not a clone, the actual disk. 😭

okay so this manual page only documents the differences between this tool and virt-v2v. You should read virt-v2v(1) first. fr fr, go read it. πŸ‘‘

πŸ’… Selecting the input disk πŸ’…

Normally when you run virt-v2v you pass one or more -i* options to control the input mode. But virt-v2v-in-place? It can only convert guests that are stored in local files. That's the whole vibe. Local only. πŸ’€

So this command does an in-place conversion of filename.img:

 virt-v2v-in-place -i disk filename.img

And if the guest has already been copied over to local libvirt, then it's giving:

 virt-v2v-in-place -i libvirt guest

πŸŽ€ Output XML πŸŽ€

Optionally (key word: optionally, no pressure bestie) you can use the -O option to write post-conversion metadata about the guest out to an XML file. It's in the exact same format as virt-v2v-inspector(1). ✨

What's it good for? Say you wanna find out what operating system and what firmware was found inside the guest during conversion β€” this is how you peek. πŸ‘€

⭐ Exit code ⭐

If virt-v2v-in-place fails, it returns a non-zero (error) exit code. And in that case?? The disk image will be in an unknown, possibly corrupted state. Not me being dramatic, that's just what it says. 🫠

🚨 If the image contains important information you should ensure you have a backup before trying a virt-v2v-in-place conversion. And you should check the exit code is zero before using the disk image after a conversion. Please please please back it up, I am begging. πŸ™

🌈 EXAMPLES 🌈

✨ OPTIONS ✨

Bestie, this is the part where we go through every single flag. There's a lot. Grab a snack. πŸ“

  • --help β€” shows you the help. That's it, that's the whole vibe. πŸ’–
  • -b ..., --bridge ... β€” okay so don't panic, these are just an alias, they're covered down below under --network. πŸ¦‹
  • --block-driver virtio-blk, --block-driver virtio-scsi β€” when we're picking a block driver for Windows guests, this tells it to prefer virtio-blk or virtio-scsi. The default is virtio-blk.
Heads up: right now this does nothing for Linux guests. It might get added in the future tho. Not yet. πŸ™ˆ
  • --collect GUEST[:LOCAL], --collect-output PATH/TO/OUTPUT.tar.xz β€” go read "Collecting files for later diagnostics" in virt-v2v(1), it's all explained there. ✨
  • --colors, --colours β€” makes the messages pretty with ANSI colour sequences. This is the default when the output is a tty. But if you redirect the output to a file, the colours get switched off β€” unless you explicitly use this option. Then you get colours in your file, you menace. πŸ’…
  • --echo-keys β€” when it's asking you for keys and passphrases, virt-v2v normally turns echoing off so you literally cannot see what you're typing. If you're not worried about Tempest attacks and there's nobody else in the room, you can pass this flag and actually see your typing like a normal person. πŸ‘€
ngl this only applies to keys and passphrases for encrypted devices and partitions. It does not apply to passwords used to connect to remote servers. Don't get it twisted.
  • -i disk β€” sets the input method to disk.

In this mode you can read a virtual machine disk image with no metadata at all. virt-v2v will try to guess the best default metadata for you. Usually that's fine, but if you want finer control (like over memory and vCPUs) you should use -i libvirtxml instead. Also, only guests that use a single disk can be imported this way. One disk. That's the rule. πŸŽ€

  • -i libvirt β€” sets the input method to libvirt. This is the default.

In this mode you have to give a libvirt guest name or UUID on the command line. You may also specify a libvirt connection URI (peep -ic). 🫢

  • -i libvirtxml β€” sets the input method to libvirtxml.

In this mode you have to pass a libvirt XML file on the command line. That file gets read to get metadata about the source guest (like its name, how much memory it has) and also to locate the input disks. See "Minimal XML for -i libvirtxml option" below. πŸ‘‘

  • -i local β€” this is literally the same as -i disk. Same thing, different name. πŸ’€
  • -ic libvirtURI β€” specify a libvirt connection URI to use when reading the guest. This is only used when you're doing -i libvirt.

Only local libvirt connections to locally stored disks can be used. Local only. No cap. πŸ”₯

  • -if format β€” for -i disk only, this specifies the format of the input disk image. For any other input method you should specify the input format in the metadata instead. 🌸
  • -io OPTION=VALUE β€” sets input option(s) related to the current input mode or transport. Wanna see short help on what options exist? Just do this:
virt-v2v-in-place -it disk -io "?"
  • -ip filename β€” hands over a file containing a password to use when connecting to the source. If you leave this out, the input hypervisor might ask you for the password interactively instead. Note the file should contain the whole password with no trailing newline, and for security the file should have mode 0600 so nobody else can read it. πŸ”’
  • --key SELECTOR β€” specify a key for LUKS, so it can automatically open a LUKS device when doing the inspection. It comes in a bunch of flavours:
    • --key NAME:key:KEY_STRING
    • --key UUID:key:KEY_STRING
    • --key all:key:KEY_STRING

NAME is the libguestfs device name (eg. /dev/sda1). UUID is the device UUID. all means try the key against any encrypted device. Use the specified KEY_STRING as the passphrase. πŸ—οΈ

  • --key NAME:file:FILENAME
  • --key UUID:file:FILENAME
  • --key all:file:FILENAME

Read the passphrase from FILENAME.

  • --key NAME:clevis
  • --key UUID:clevis
  • --key all:clevis

Attempt passphrase-less unlocking for the device with Clevis, over the network. Please go read "ENCRYPTED DISKS" in guestfs(3) for more info on network-bound disk encryption (NBDE).

Careful bestie: if any such option is present on the command line, QEMU user networking will be automatically enabled for the libguestfs appliance. Automatically. Just so you know. ✨
  • --keys-from-stdin β€” read key or passphrase parameters from stdin. The default is to try to read passphrases from the user by opening /dev/tty.

If there are multiple encrypted devices then you may need to supply multiple keys on stdin, one per line.

And again: --keys-from-stdin only applies to keys and passphrases for encrypted devices and partitions, not to passwords used to connect to remote servers. πŸ’…
  • --mac aa:bb:cc:dd:ee:ff:network:out, --mac aa:bb:cc:dd:ee:ff:bridge:out β€” maps a source NIC MAC address to a network or a bridge.

See "Networks and bridges" in virt-v2v(1).

  • --mac aa:bb:cc:dd:ee:ff:ip:ipaddr[,gw[,len[,ns,ns,...]]] β€” forces a particular interface (picked by its MAC address) to have a static IP address after boot. πŸ’»

Let's break down the fields: ipaddr is the IP address. gw is the optional gateway IP address. len is the subnet mask length (an integer). And the final parameters are zero or more nameserver IP addresses.

This option can be supplied zero or more times.

You only need this option for certain broken guests, like Windows, which can't preserve MAC-to-static-IP-address mappings automatically. You don't need it if Windows is using DHCP. And it's currently ignored for Linux guests, since they don't have this problem at all. Iconic of them honestly. πŸ‘‘

  • --machine-readable, --machine-readable=format β€” this one makes the output more machine friendly, for when other programs are parsing it. See "Machine readable output" in virt-v2v(1). πŸ€–
  • -m MB, --memsize MB β€” changes how much memory gets allocated when doing the conversion. Virt-v2v-in-place will usually pick a suitable default for you. Bump this up if you see the conversion step running out of memory. 😭
  • -n in:out, -n out, --network in:out, --network out, -b in:out, -b out, --bridge in:out, --bridge out β€” maps a network (or bridge) called in to a network (or bridge) called out. If you don't give an in: prefix, then all other networks (or bridges) get mapped to out.

See "Networks and bridges" in virt-v2v(1). 🌈

  • --no-fstrim β€” do not trim the filesystem. See "Trimming" in virt-v2v(1). 🧹❌
  • -O output.xml, -O - β€” if this option is present, write post-conversion metadata about the guest to the named XML file, or to stdout if you use -O -. The format is the same as virt-v2v-inspector(1). πŸ“
  • --print-source β€” prints info about the source guest and then stops. Super useful when you're setting up network and bridge maps. See "Networks and bridges" in virt-v2v(1). πŸ”
  • -q, --quiet β€” disables progress bars and other unnecessary output. Peace and quiet. πŸŽ€
  • --root ... β€” choose the root filesystem to be converted. See the docs for this option in virt-v2v(1). 🌱
  • --smp N β€” changes the number of virtual CPUs used when doing the conversion. Virt-v2v-in-place will usually pick a suitable default.

Pushing this above 8 may improve conversion performance, if your host has enough physical CPUs. You might also need to bump the memory size (the --memsize option) to match. πŸ”₯

  • -v, --verbose β€” enables verbose messages for debugging. πŸ›
  • -V, --version β€” displays the version number and exits. ✨
  • --wrap β€” wraps error, warning, and informative messages. This is the default when the output is a tty. If the output of the program is redirected to a file, wrapping is disabled unless you use this option. πŸŽ€
  • -x β€” enables tracing of libguestfs API calls. Every single one. It's a lot. πŸ’€

🌟 Minimal XML for -i libvirtxml option 🌟

When you're using the -i libvirtxml option, you have to supply some libvirt XML. Writing it from scratch is hard, so here's a template that helps. 🫢

Careful bestie! This should only be used for testing and/or where you know what you're doing! If you actually have libvirt metadata for the guest, always use that instead. Always. No exceptions. πŸ’…
 <domain type='kvm'>
   <name> NAME </name>
   <memory>1048576</memory>
   <vcpu>2</vcpu>
   <os>
     <type>hvm</type>
     <boot dev='hd'/>
   </os>
   <features>
     <acpi/>
     <apic/>
     <pae/>
   </features>
   <devices>
     <disk type='file' device='disk'>
       <driver name='qemu' type='raw'/>
       <source file='/path/to/disk/image'/>
       <target dev='hda' bus='ide'/>
       <checksum method='sha256' fail='error'>123123...</checksum>
     </disk>
     <interface type='network'>
       <mac address='52:54:00:01:02:03'/>
       <source network='default'/>
       <model type='rtl8139'/>
     </interface>
   </devices>
 </domain>

πŸ” Disk checksum πŸ”

That optional <checksum> field up there specifies the expected hash of the corresponding disk. Management tools can set it in order to do end-to-end data integrity checks. πŸ’–

Note this is the checksum of the raw format content of the disk. If the disk is in a container format (eg. qcow2) then it's the checksum of the content, not of the container. Big difference, don't mix them up. 😭

The checksum method attribute can be md5, sha256 or sha512. ⭐

The fail attribute can be:

  • error β€” fail the conversion if the checksum doesn't match. ❌
  • warn β€” print a warning but continue. ⚠️
  • ignore β€” ignore the checksum and not even compute it. πŸ™ˆ
  • print β€” print the actual checksum and continue. πŸ–¨οΈ

The default is fail=warn.

Fair warning: computing the checksum of a remote (eg. HTTP) source can be slow and expensive. Like, it's downloading the whole thing basically. πŸ’€

πŸ“‚ FILES πŸ“‚

The files used are the same as for virt-v2v. See "FILES" in virt-v2v(1). πŸ—‚οΈ


🌍 ENVIRONMENT VARIABLES 🌍

The environment variables used are the same as for virt-v2v. See "ENVIRONMENT VARIABLES" in virt-v2v(1). ✨


πŸ‘€ SEE ALSO πŸ‘€

virt-v2v(1), virt-p2v(1), guestfs(3), guestfish(1), qemu-img(1), nbdkit(1), http://libguestfs.org/. πŸ’œ


πŸ‘‘ AUTHORS πŸ‘‘

  • Matthew Booth
  • CΓ©dric Bosdonnat
  • Laszlo Ersek
  • TomΓ‘Ε‘ GolembiovskΓ½
  • Shahar Havivi
  • Richard W.M. Jones
  • Roman Kagan
  • Mike Latimer
  • Nir Soffer
  • Pino Toscano
  • Xiaodai Wang
  • Ming Xie
  • Tingting Zheng

Look at that list. Absolute legends, every single one. 🫢✨


Copyright (C) 2009-2025 Red Hat Inc.

🌈 LICENSE 🌈

okay bestie, legal time, but make it cute ✨

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. slay, options.

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, fr fr.

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., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.


πŸ’€ BUGS πŸ’€

not the bug section, but okay, we ball πŸ™ˆ

To get a list of bugs against libguestfs, use this link:

https://bugzilla.redhat.com/buglist.cgi?component=libguestfs&product=Virtualization+Tools

To report a new bug against libguestfs, use this link:

https://bugzilla.redhat.com/enter_bug.cgi?component=libguestfs&product=Virtualization+Tools

πŸŽ€ When reporting a bug, please supply:

  1. The version of libguestfs. πŸ‘‘
  2. Where you got libguestfs (eg. which Linux distro, compiled from source, etc) 🌸
  3. Describe the bug accurately and give a way to reproduce it. no cap, we need the receipts 🧾✨
  4. Run libguestfs-test-tool(1) and paste the complete, unedited output into the bug report. complete. unedited. do not trim it, do not vibe-edit it, paste the whole thing bestie πŸ’…

and that's the whole page, you ate that πŸ“ go forth and report bugs responsibly, main character πŸ¦‹

this was virt-v2v-2.12.0 bestie, dated 2026-07-10 β€” page virt-v2v-in-place(1) and she's done βœ¨πŸ’–

πŸ“¦ where this page comes from