[Libguestfs] 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@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