Virt-p2v is a physical-to-virtual migration tool, for turning physical computers into virtual machines running under some virtualization environment like Xen.
The tool is packaged as a live CD, based on a Fedora 8 distribution, and using livecd-creator to build the ISO.
Main page: http://et.redhat.com/~rjones/virt-p2v/ Source repo: http://hg.et.redhat.com/virt/applications/virt-p2v--devel
I'm posting here to see if anyone has any comments about the way I did this live CD. The kickstart script uses a rather complex %post section, which adds a few files to the filesystem, instead of building RPMs or modifying existing RPMs.
I've also investigated how to attach stuff to the end of the ISO image, and the way I've come up with allows me to update an ISO with a new script quite easily, and much more quickly than waiting for livecd-creator to rerun. This great (a) for rapid development and (b) to send new updates to users without forcing them to download another 170 MB ISO.
I'd like to package this for Fedora. Obviously I don't want to package the binary live CD, but instead package the kickstart file and some tools to allow people to easily build custom live CDs. If anyone has any ideas or examples of this I'd be interested to hear.
Thanks, Rich.
On Mon, 2008-02-04 at 19:05 +0000, Richard W.M. Jones wrote:
I'm posting here to see if anyone has any comments about the way I did this live CD. The kickstart script uses a rather complex %post section, which adds a few files to the filesystem, instead of building RPMs or modifying existing RPMs.
From a maintainability point of view, you're going to be happier in the
long run if you actually package up things into RPMs as opposed to just concatenating piles of scripts. I've already gotten pretty frustrated with just the initscript we're using in the desktop case on a few occasions.
I've also investigated how to attach stuff to the end of the ISO image, and the way I've come up with allows me to update an ISO with a new script quite easily, and much more quickly than waiting for livecd-creator to rerun. This great (a) for rapid development and (b) to send new updates to users without forcing them to download another 170 MB ISO.
Ewwww :)
Jeremy
As a not-quite-counter argument, I've found that if each change is small (e.g. three sed commands to tweak a config), a longer kickstart can make a lot of sense. Beyond short stuff, I will agree completely with Jeremy. RPMs are not too hard to pull off if you have a little patience on the first one. Guru labs has a nice tutorial you can google (the examples are google-able, too ... they just arn't in the same place)
On embedding stuff in the kickstart, one suggestion. Use some sort of really really obvious delimiter and extra white space between each chunk (see the example below). I've got a kickstart that tweaks a bunch of odds & ends in %post and this approached has saved my sanity and made maintenance and improvement much easier.
Tim Wood
############################## # # tweak the config for foo
[some lines]
############################## # # copy the files for bar
[some lines]
Jeremy Katz wrote:
On Mon, 2008-02-04 at 19:05 +0000, Richard W.M. Jones wrote:
I'm posting here to see if anyone has any comments about the way I did this live CD. The kickstart script uses a rather complex %post section, which adds a few files to the filesystem, instead of building RPMs or modifying existing RPMs.
From a maintainability point of view, you're going to be happier in the
long run if you actually package up things into RPMs as opposed to just concatenating piles of scripts. I've already gotten pretty frustrated with just the initscript we're using in the desktop case on a few occasions.
I've also investigated how to attach stuff to the end of the ISO image, and the way I've come up with allows me to update an ISO with a new script quite easily, and much more quickly than waiting for livecd-creator to rerun. This great (a) for rapid development and (b) to send new updates to users without forcing them to download another 170 MB ISO.
Ewwww :)
Jeremy
-- Fedora-livecd-list mailing list Fedora-livecd-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list
Jeremy Katz wrote:
On Mon, 2008-02-04 at 19:05 +0000, Richard W.M. Jones wrote:
I'm posting here to see if anyone has any comments about the way I did this live CD. The kickstart script uses a rather complex %post section, which adds a few files to the filesystem, instead of building RPMs or modifying existing RPMs.
From a maintainability point of view, you're going to be happier in the
long run if you actually package up things into RPMs as opposed to just concatenating piles of scripts. I've already gotten pretty frustrated with just the initscript we're using in the desktop case on a few occasions.
So there are two genuine issues with using RPMs:
(1) I need to replace existing files -- in particular I need a new /etc/inittab. AIUI to do this with RPMs would involve building a custom 'initscripts' RPM and maintaining it, but let me know if I've got that wrong.
(2) I'd like users to be able to download the source tarball and do:
./configure make
to build an ISO. However the intermediate step -- building RPMs -- requires a full RPM build root inside the user's home directory, so they'd need to set that up and create the ~/.rpmmacros file, and specify where it is to ./configure. Again, that's AIUI, please correct me if I'm wrong.
I've also investigated how to attach stuff to the end of the ISO image, and the way I've come up with allows me to update an ISO with a new script quite easily, and much more quickly than waiting for livecd-creator to rerun. This great (a) for rapid development and (b) to send new updates to users without forcing them to download another 170 MB ISO.
Ewwww :)
OK funny, but there's a genuine reason for doing this.
P2V is extremely difficult to test; I'd like to compare it to debugging software in outer space. In all cases where someone has reported a bug to me I've had no access to the hardware, and no way to build comparable hardware at home (often it's because they're using some oddball SCSI controller or RAID array). I'm relying on a third party to give me as many details as possible. I then run the program through on paper to see if there are any scenarios which would give rise to the same bug. I then make a small change to the script, and send them another ISO to test.
The problem is that it takes an hour and a half to upload a 170MB ISO, and another 15 minutes for the third party to download it.
The only change may be a couple of lines in a 1,000 line script which I could send to them by email in seconds.
ISO attachments allow much more interactive testing.
Rich.
On Tue, 2008-02-05 at 10:22 +0000, Richard W.M. Jones wrote:
Jeremy Katz wrote:
On Mon, 2008-02-04 at 19:05 +0000, Richard W.M. Jones wrote:
I'm posting here to see if anyone has any comments about the way I did this live CD. The kickstart script uses a rather complex %post section, which adds a few files to the filesystem, instead of building RPMs or modifying existing RPMs.
From a maintainability point of view, you're going to be happier in the
long run if you actually package up things into RPMs as opposed to just concatenating piles of scripts. I've already gotten pretty frustrated with just the initscript we're using in the desktop case on a few occasions.
So there are two genuine issues with using RPMs:
(1) I need to replace existing files -- in particular I need a new /etc/inittab. AIUI to do this with RPMs would involve building a custom 'initscripts' RPM and maintaining it, but let me know if I've got that wrong.
An entirely new inittab seems... overkill. Is an initscript to run your functionality not good enough?
(2) I'd like users to be able to download the source tarball and do: ./configure make to build an ISO. However the intermediate step -- building RPMs -- requires a full RPM build root inside the user's home directory, so they'd need to set that up and create the ~/.rpmmacros file, and specify where it is to ./configure. Again, that's AIUI, please correct me if I'm wrong.
--define _builddir, etc on the rpmbuild command line works. And you can then put it under a mktemp'd directory.
I've also investigated how to attach stuff to the end of the ISO image, and the way I've come up with allows me to update an ISO with a new script quite easily, and much more quickly than waiting for livecd-creator to rerun. This great (a) for rapid development and (b) to send new updates to users without forcing them to download another 170 MB ISO.
Ewwww :)
OK funny, but there's a genuine reason for doing this.
Sure, but it's going to be pretty fragile and I know I'd rather have something more dependable. Why not just use something like xdelta between isos? A little more time-consuming to create, but I suspect that time difference is already made up with the time you spent writing the ocaml script :-)
Jeremy
Jeremy Katz wrote:
An entirely new inittab seems... overkill. Is an initscript to run your functionality not good enough?
No, I used to do it like that, and it was problematic.
This was many months ago so I'm a bit vague on the exact details but it would have been something to do with either getting stdin/stdout to the tty or having /sbin/init unexpectedly put up a prompt during or after my initscript running.
The current method (modifying inittab) works well anyway.
Rich.
livecd@lists.fedoraproject.org
-
Jeremy Katz -
Richard W.M. Jones -
Tim Wood