[virt-tools-list] what does virt-v2v check for in a multiboot os?

[Kenneth Armstrong]

"Unfortunately not. It can't inspect the guest to determine that it
can't convert it until it has copied it. It's the copy that takes the
time. Creating the new target volume and conversion only take a minute
or so."

Is that just a limitation of libguestfs not able to read a vmdk image?
 Would it be possible to have that feature in the future, to expedite
a conversion (or at least check to see if a conversion is even
possible?)

-Kenny

On Wed, Jan 26, 2011 at 9:15 AM, Kenneth Armstrong <digimars at gmail.com> wrote:
> Well, I uninstalled the recovery console because of that reason.  It
> shows up in the boot.ini file and gets its own boot loader.  But even
> after the removal of the recovery console, it fails.  I assume it's
> because I had two partitions on the vm, because after I deleted the
> (empty) second partition, it was able to work with it.  But again,
> deleting other partitions on systems that have important data on them
> won't work in a production environment.
>
> -Kenny
>
> On Wed, Jan 26, 2011 at 9:10 AM, Matthew Booth <mbooth at redhat.com> wrote:
>> On 26/01/11 13:56, Kenneth Armstrong wrote:
>>>
>>> Thanks Rich,
>>>
>>> I tried this again and it still failed.  This is a single vmdk disk
>>> with two partitions.  I deleted out the second partition (that didn't
>>> have anything on it) and it worked.  However, i have other vm's to
>>> import that I can't delete out the second partition, so that isn't
>>> ideal.
>>>
>>> I was looking through the virt-v2v script itself (this is on RHEL 6)
>>> and noticed that it was supposed to run the inspection before it
>>> creates the target vm image (I'm no PERL guy, but that's what I got
>>> from the script).  However, when I run the utitlity, it goes through
>>> the whole process of creating the target vm (which took about 2.5
>>> hours on my last try) and then failed because "multiboot operating
>>> systems are not supported by virt-v2v."
>>>
>>> Could the utility be changed to check that before it tries to convert
>>> it?  That would save a lot of time from being wasted by a process that
>>> won't work.
>>
>> Unfortunately not. It can't inspect the guest to determine that it can't
>> convert it until it has copied it. It's the copy that takes the time.
>> Creating the new target volume and conversion only take a minute or so.
>>
>> It's my understanding that the recovery console is installed on a separately
>> bootable partition which is normally hidden from Windows, and that it
>> contains a stripped-down Windows installation. Is that right? If so, it
>> explains the problem you're seeing. virt-inspector would see this as a
>> second OS. virt-v2v would see multiple OSs and refuse to convert it. If so,
>> we obviously need to handle this.
>>
>> Matt
>> --
>> Matthew Booth, RHCA, RHCSS
>> Red Hat Engineering, Virtualisation Team
>>
>> GPG ID:  D33C3490
>> GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
>>
>