[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Libguestfs] some thoughts about virt-v2v (including matt's reply)

From matt :


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

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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]