Description of problem: virt-inspector should produce OVF output, so that oVirt / RHEV can directly import unknown disk images. Version-Release number of selected component (if applicable): Target: libguestfs 1.22 for Fedora 19 / RHEL 7 Attached are two example OVF files supplied by the oVirt team.
Created attachment 708953 [details] example1.ovf
Created attachment 708954 [details] example2.ovf
Some items that are in the OVF and not collected by inspection / virt-inspector currently: + creation date (of VM? or of the OVF file?) You can get the creation date of a VM by looking for the oldest file in a common directory, eg. /etc or /Windows/system32. + MinAllocatedMem We would get this information from the libosinfo database. http://libosinfo.org/ + number of vCPUs I doubt Linux stores this specifically, but it would be available by parsing through the log files for the last boot. The Windows Registry might have it. We could get min/max values from libosinfo. + vCPU layout (ie. sockets, cores, threads) Probably we'd standardize this or ask the user. + memory size As for vCPUs above. + ovf:volume-format="RAW" + ovf:volume-type="Sparse" We can get this from the image itself. + ovf:disk-interface="VirtIO" We don't currently try to collect this in virt-inspector, but it should be possible to look at the initrd or log files (for Linux). Or the CriticalDeviceDatabase (Windows). + DefaultDisplayType Parse X config? In the Windows Registry? + network card adapter: MAC addr + network card adapter: speed + network card apapter: "ResourceSubType" For Linux, could get this either by parsing log files (which would be most accurate) or by looking at /etc/sysconfig files. For Windows, this is stored in the Registry. + USB adapter I've no idea about this, but the OVF files supplied didn't seem to contain much information either. What's also interesting is the information that we have from inspection that's NOT contained in the OVF. For example, the guest operating system type, version, etc.
Created attachment 708989 [details] virt-inspector-fedora-18.xml For completeness, the output of virt-inspector on a Fedora 18 guest.
I had a chat to danpb re comment 3 and he thinks and I agree that we should use libosinfo to provide the defaults for most settings (certainly: suggested RAM, whether to enable virtio disk or NICs). It will be more predictable and less voodoo. There's also bound to be some admin configuration needed, eg. selecting the right number of vCPUs for the anticipated load.