Re: [Libguestfs] [PATCH v2v] New virt-v2v-inspector tool

In Kubernetes and tools like Kubevirt, it's not possible to create some disks and then attach to them (in order to populate them with data) in one step. This makes virt-v2v conversions awkward because ideally we would like the output mode (-o kubevirt) to both create the target disks and populate them at the same time. So to work around this problem, we need a tool which can inspect the virt-v2v source hypervisor before we do the conversion in order to find out how many disks are needed and their sizes. Then we can create the target disks, and then we can run a second container with virt-v2v attached to the disks to do the conversion and populate the output.

n This is a proposed tool to do this. It essentially uses the same -i* options as virt-v2v (and no -o* options) and outputs various useful metadata. Example: $ ./run virt-v2v-inspector --quiet -i disk /var/tmp/fedora-32.img virt-v2v-inspector: The QEMU Guest Agent will be installed for this guest at first boot. virt-v2v-inspector: warning: /files/boot/grub2/device.map/hd0 references unknown device "vda". You may have to fix this entry manually after conversion. <?xml version='1.0' encoding='utf-8'?> <v2v-inspection> <!-- generated by virt-v2v-inspector 2.1.9local,libvirt --> <program>virt-v2v-inspector</program> <package>virt-v2v</package> <version>2.1.9</version> <disks> <disk index='0'> <virtual-size>6442450944</virtual-size> <allocated estimated='true'>1400897536</allocated> </disk> </disks> <operatingsystem> <name>linux</name> <distro>fedora</distro> <osinfo>fedora32</osinfo> <arch>x86_64</arch> <major_version>32</major_version> <minor_version>0</minor_version> <package_format>rpm</package_format> <package_management>dnf</package_management> <product_name>Fedora 32 (Thirty Two)</product_name> </operatingsystem> </v2v-inspection> There should be sufficient information in the <disks> section to allocate target disks, plus additional information is printed which might be useful. Note that we do a full conversion in order to generate this information. In particular it's not possible to generate the <allocated/> estimate without this. It's plausible we could have a --no-convert option, but I'm not sure it's worthwhile: it would only save a little time, but would make everything less accurate, plus maybe it is a good idea to find out if conversion is going to work before we create the target disks?

I chose XML instead of JSON for output. XML allows us to annotate elements with attributes like "estimated='true'". It also lets us represent 64 bit number accurately, where JSON cannot represent such numbers. One obvious problem is that (without --quiet) the program mixes up informational output with the final document, which is a bit of a pain. Ideas here?