10:29 a.m.
Hi,
I have recently been looking into virt-v2v, and noticed the mention of an upcoming rewrite
in a few places. Is there a roadmap or post someplace that describes the future of this
project?
I've got a couple of patches against the current code base, and am wondering if they
will still be considered for inclusion.
Thanks,
Mike
1:52 p.m.
On Tue, Sep 03, 2013 at 09:29:49AM -0600, Mike Latimer wrote:
Hi,
I'll make some advisory comments, but you really need to talk to Matt
Booth (CC'd - or mdbooth on #libguestfs).
I have recently been looking into virt-v2v, and noticed the mention
of an upcoming rewrite in a few places. Is there a roadmap or post
someplace that describes the future of this project?
Even better, there is a repo: https://github.com/mdbooth/guestconv
Matt - can you push your latest commits, or is there a more canonical
repo that Mike can look at?
I've got a couple of patches against the current code base, and
am
wondering if they will still be considered for inclusion.
Yes, for virt-v2v (or guestconv if you want too). Post patches on
this mailing list.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
6:10 p.m.
On Tuesday, September 03, 2013 07:52:08 PM Richard W.M. Jones wrote:
Even better, there is a repo: https://github.com/mdbooth/guestconv
Excellent. Thanks for the pointer.
Matt - can you push your latest commits, or is there a more
canonical
repo that Mike can look at?
The last changes in the repo seem to be from back in June. Is guestconv
expected to completely replace virt-v2v in RHEL7?
> I've got a couple of patches against the current code base,
and am
> wondering if they will still be considered for inclusion.
Yes, for virt-v2v (or guestconv if you want too). Post patches on
this mailing list.
Great. I've got some code which adds support for openSUSE/SLES into virt-v2v
(based on the RedHat.pm converter). Along the way, I ran into a couple of
small issues which affect RHEL as well. I'll post those changes here for
review, and possibly begin a discussion surrounding the SUSE side of things.
Thanks,
Mike
6 a.m.
On Tue, 2013-09-03 at 17:10 -0600, Mike Latimer wrote:
On Tuesday, September 03, 2013 07:52:08 PM Richard W.M. Jones wrote:
> Even better, there is a repo: https://github.com/mdbooth/guestconv
Excellent. Thanks for the pointer.
> Matt - can you push your latest commits, or is there a more canonical
> repo that Mike can look at?
The last changes in the repo seem to be from back in June. Is guestconv
expected to completely replace virt-v2v in RHEL7?
Yeah, I've been a bit lax in pushing stuff to guestconv. Also,
development on it hasn't gone nearly as quickly as I'd have liked
lately. I've just gotten back to it, though. I'm in the middle of a
change right now, but I'll try to get it pushed RSN.
guestconv is not intended to completely replace virt-v2v. Broadly
speaking, virt-v2v does 2 things:
1. Move guests between 2 hypervisors.
2. Make changes to the guest required for a new hypervisor.
The second is unique to virt-v2v, the first has other tools out there.
guestconv will only replace the second bit, and will expose this
functionality as a library. guestconv will also target more combinations
of source and target hypervisor, and allow more control over the
conversion process.
> > I've got a couple of patches against the current code
base, and am
> > wondering if they will still be considered for inclusion.
>
> Yes, for virt-v2v (or guestconv if you want too). Post patches on
> this mailing list.
+1. I've been adding to virt-v2v this week.
Great. I've got some code which adds support for openSUSE/SLES
into virt-v2v
(based on the RedHat.pm converter). Along the way, I ran into a couple of
small issues which affect RHEL as well. I'll post those changes here for
review, and possibly begin a discussion surrounding the SUSE side of things.
Yes, please. You had some questions in another email about grubby.
There's no fundamental reason to require grubby. In fact, if you look
back through the git history we didn't originally require it. However,
it simplified things because it supports both grub legacy and grub 2
(whose configuration has been classified as a form of torture by the
UN). I can't think of any good reason you couldn't install grubby early
in the conversion process and use it later. However, I would *not*
re-use the user-custom installation for this. If installation of grubby
is critical to the conversion process, give it its own entry in
virt-v2v.db.
The pre-convert idea is one we've tried to avoid in the past, although
I'm by no means 100% against it. If we decided to go fully down that
route, it would certainly allow us to remove a ton of code and greatly
simplify testing. Hmm...
You also mentioned the logging. Yes, logging is sparse in virt-v2v; it
will be better in guestconv. It's lame in virt-v2v because we didn't
consider it important early, and didn't retrofit it later. However, you
have to consider what the logging is for. If it's just for debugging,
nothing is likely to beat LIBGUESTFS_TRACE. I would keep logging to:
1. Debugging information which won't be captured by LIBGUESTFS_TRACE,
because it doesn't involve a libguestfs api call.
2. Information about the conversion which is of use to the end user.
If you have any ideas on what the second set is, that would be very
interesting.
Thanks,
Matt
10:31 a.m.
On Thursday, September 05, 2013 12:00:44 PM Matthew Booth wrote:
guestconv is not intended to completely replace virt-v2v. Broadly
speaking, virt-v2v does 2 things:
1. Move guests between 2 hypervisors.
2. Make changes to the guest required for a new hypervisor.
The second is unique to virt-v2v, the first has other tools out there.
guestconv will only replace the second bit, and will expose this
functionality as a library. guestconv will also target more combinations
of source and target hypervisor, and allow more control over the
conversion process.
Thanks for the clarification. I'll keep tabs on the repo, and contribute from
the SUSE side.
Yes, please. You had some questions in another email about grubby.
There's no fundamental reason to require grubby. In fact, if you look
back through the git history we didn't originally require it. However,
it simplified things because it supports both grub legacy and grub 2
(whose configuration has been classified as a form of torture by the
UN). I can't think of any good reason you couldn't install grubby early
in the conversion process and use it later. However, I would *not*
re-use the user-custom installation for this. If installation of grubby
is critical to the conversion process, give it its own entry in
virt-v2v.db.
Yes, after the grub2 config segment on C-SPAN last night, I'd rather just let
grubby take care of the dirty work.
The pre-convert idea is one we've tried to avoid in the past,
although
I'm by no means 100% against it. If we decided to go fully down that
route, it would certainly allow us to remove a ton of code and greatly
simplify testing. Hmm...
Ok. I'll finish the SUSE converter with one of those solutions and we can
discuss it further after it's posted.
You also mentioned the logging. Yes, logging is sparse in virt-v2v;
it
will be better in guestconv. It's lame in virt-v2v because we didn't
consider it important early, and didn't retrofit it later. However, you
have to consider what the logging is for. If it's just for debugging,
nothing is likely to beat LIBGUESTFS_TRACE.
LIBGUESTFS_TRACE is more than enough to monitor the conversion itself. I was
specifically thinking a little higher level anyway.
I would keep logging to:
1. Debugging information which won't be captured by LIBGUESTFS_TRACE,
because it doesn't involve a libguestfs api call.
2. Information about the conversion which is of use to the end user.
I definitely agree that additional logging would be helpful in the above areas.
Initially, I just wanted to add some basic progress type of messages as you go
through the virt-v2v stages. (Connecting to host, analyzing guest, copying
storage, inspecting, converting, creating...). I have also thought about a
summary of the conversion process, and what might be useful there. I'll flush
my thoughts out and start a new thread for additional comments.
Thanks,
Mike
10:47 a.m.
On Thu, 2013-09-05 at 09:31 -0600, Mike Latimer wrote:
On Thursday, September 05, 2013 12:00:44 PM Matthew Booth wrote:
> guestconv is not intended to completely replace virt-v2v. Broadly
> speaking, virt-v2v does 2 things:
>
> 1. Move guests between 2 hypervisors.
> 2. Make changes to the guest required for a new hypervisor.
>
> The second is unique to virt-v2v, the first has other tools out there.
> guestconv will only replace the second bit, and will expose this
> functionality as a library. guestconv will also target more combinations
> of source and target hypervisor, and allow more control over the
> conversion process.
Thanks for the clarification. I'll keep tabs on the repo, and contribute from
the SUSE side.
> Yes, please. You had some questions in another email about grubby.
> There's no fundamental reason to require grubby. In fact, if you look
> back through the git history we didn't originally require it. However,
> it simplified things because it supports both grub legacy and grub 2
> (whose configuration has been classified as a form of torture by the
> UN). I can't think of any good reason you couldn't install grubby early
> in the conversion process and use it later. However, I would *not*
> re-use the user-custom installation for this. If installation of grubby
> is critical to the conversion process, give it its own entry in
> virt-v2v.db.
Yes, after the grub2 config segment on C-SPAN last night, I'd rather just let
grubby take care of the dirty work.
> The pre-convert idea is one we've tried to avoid in the past, although
> I'm by no means 100% against it. If we decided to go fully down that
> route, it would certainly allow us to remove a ton of code and greatly
> simplify testing. Hmm...
Ok. I'll finish the SUSE converter with one of those solutions and we can
discuss it further after it's posted.
> You also mentioned the logging. Yes, logging is sparse in virt-v2v; it
> will be better in guestconv. It's lame in virt-v2v because we didn't
> consider it important early, and didn't retrofit it later. However, you
> have to consider what the logging is for. If it's just for debugging,
> nothing is likely to beat LIBGUESTFS_TRACE.
LIBGUESTFS_TRACE is more than enough to monitor the conversion itself. I was
specifically thinking a little higher level anyway.
> I would keep logging to:
> 1. Debugging information which won't be captured by LIBGUESTFS_TRACE,
> because it doesn't involve a libguestfs api call.
> 2. Information about the conversion which is of use to the end user.
I definitely agree that additional logging would be helpful in the above areas.
Initially, I just wanted to add some basic progress type of messages as you go
through the virt-v2v stages. (Connecting to host, analyzing guest, copying
storage, inspecting, converting, creating...). I have also thought about a
summary of the conversion process, and what might be useful there. I'll flush
my thoughts out and start a new thread for additional comments.
It turns out that progress logging during the conversion isn't all that
useful. This is because the profile of any conversion is dominated by
the copy process. And when I say dominated, I mean potentially hours to
copy guest data, followed by about 1 minute of conversion. It's
certainly not useful in real time, because the user will have wandered
off to get coffee long before the conversion process starts, and likely
won't see it!
Incidentally, you mention an 'analyzing' step. virt-v2v doesn't really
have one. It copies, then analyzes and converts in 1 go. One of the
design goals of guestconv is to allow us to split it into the stages you
suggest above by having a separate 'inspection' stage.
Matt
1:33 p.m.
On Thursday, September 05, 2013 04:47:09 PM you wrote:
It turns out that progress logging during the conversion isn't
all that
useful. This is because the profile of any conversion is dominated by
the copy process. And when I say dominated, I mean potentially hours to
copy guest data, followed by about 1 minute of conversion. It's
certainly not useful in real time, because the user will have wandered
off to get coffee long before the conversion process starts, and likely
won't see it!
Very good points.
Incidentally, you mention an 'analyzing' step. virt-v2v
doesn't really
have one. It copies, then analyzes and converts in 1 go. One of the
design goals of guestconv is to allow us to split it into the stages you
suggest above by having a separate 'inspection' stage.
Yes, the 'analyzing' step I was referring to was really just between
connecting to the source, and beginning the storage copy. You can error out
here (if the guest is running, or already exists on the target), and I thought
some indication of what was going on would be useful.
Progress messages of some form seem to be useful before the file copy starts.
For example, if SSH keys are not in use, you can get two password prompt in a
row, which can be a bit confusing. (Anyone doing a lot of this would certainly
have SSH keys in place though.)
The remaining messages might be better kept in a summary fashion though...
I'll think about it from that perspective.
-Mike
4098
days inactive
4100
days old
6 comments
3 participants
participants (3)
-
Matthew Booth -
Mike Latimer -
Richard W.M. Jones