Libguestfs - Dec 2009 - some thoughts about virt-v2v (including matt's reply)

From matt :

Osier,

Comments inline below.

On 18/12/09 07:39, Osier Yang wrote:
> and another point.
>
> the messages printed to stdout or stderr are not with "message
level".
> such as
> [root at dhcp-66-70-131 image]# virt-v2v -i libvirtxml demo1.xml
> virt-v2v: The connected hypervisor does not support a machine type of pc.
> virt-v2v: demo1 configured with virtio drivers
>
> The user won't known whether "virt-v2v: The connected hypervisor
does
> not support a machine type of pc." is a warning or error. :)
Yup, that could be improved.
>
> Osier Yang wrote:
>> hi, mbooth.
>>
>> just some thoughts about virt-v2v, hope it's not invalid. :)
>>
>> 1. when we convert a guest on xen. we should do as following:
>> 1> dump the guest xml
>> 2> copy the guest xml and image to the the machine on which virt-v2v
>> will run.
>> 3> mv the guest image to "/var/lib/libvirt/images"
>> 4> change the path of guest image "<source
>> file="/var/lib/xen/images/guest.img">" into
"<source
>> file="/var/lib/libvirt/images/guest.img">"
>>
>> what I think is could we add an option of virt-v2v so that the user
>> can specify the new path of the guest image, add the script help the
>> user do
>> the replacement, such as:
>> # virt-v2v -i libvirtxml guest.xml --image=/tmp/guest.img
>>
>> Think it's more convenient.
Yes, I definitely need to do something much cleverer with storage 
changing path. With the addition of support for VMWare guests I'm going 
to have to sort pulling storage from a remote server, so I will have to 
address this.
>> 2. seems virt-v2v doesn't generate any log.
>> when do the testing, sometime we want to see the log to see what
>> happened. it's important somehow. libvirt provides an ENV variable
>> "LIBVIRT_DEBUG", with setting the value "1",
"2", "3", "4". diffrent
>> level messages are logged.
>> may be we can take it as a reference.
I haven't considered this before. Definitely desirable.
>> 3. when the conversion done, there is no prompt string to tell the
>> user whether it's successfull or failed.
>> think it's better if given freindly prompt string, such as :
>> # virt-v2v -i libvirtxml guest.xml --image=/tmp/guest.img
>> ........... messages ................
>> congratulations, the guest was migrated successfully, try to start it
>> using "virsh start guestname"
Related to your point about clearer output messages, I think. I agree 
this would be a good idea.
>> Of course, these are just my own thoughts without deep knownledge of
>> virt-v2v, may be some of them are not reasonable, or invalid, or
it's
>> already in the process of
>> implementing, if it is, just skip them. :-)
They're all good. Storage migration is a priority, but it's going to 
have to wait for VMWare. After this I'd say the change log was most 
important. Clearer output messages are highly desirable, but bottom of 
the pile for the moment.

In general it's probably best to send this to the libguestfs mailing 
list. Your points are extremely well made, and may prompt others to 
offer more.

Thanks,

Matt