WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] Guest O/S Questions

Anthony Liguori wrote:

Karsten M. Self wrote:

That's actually getting to be a preferred method here, at least for some folks.

qemu file-backed installs allow you to use an existing RHEL installer, without much fuss or mess, the tricky bit is finding the filesystem afterward, as what qemu produces is a _partitioned_ file with filesystems within it.


Or you can just expose as a device with a partition table. IMHO, this is the best approach.

I've even had success resizing the disk image, and then (using a boot disk), appropriately resizing the filesystem.


dd skip=63 bs=512 if=qemu.img of=xen.img

Keep in mind, I've not tried this myself :-)

Doh! I missed your skip. That should work for a partitioned file with a single partition. If you've got multiple partitions, you'd want to add the size in blocks as 'count', otherwise you're going to have multiple partitions in what you're assuming is a single filesystem image. Somewhere down the road, something's probably going to get confused, unhappy, or both, about that. Or you're just going to carry around a lot of slack space.

Are you doing this with the qemu partitioned file itself?


Yup.

My xend config line looks like this:

disk = [ 'file:/root/FC4.img,hda,w' ]
root = "/dev/hda1"


That just works. There shouldn't be any disadvantage to using this method (other than it makes resizing individual partitions a bit more difficult).

... that's on a filesystem image, not a partitioned file, though, right?

   volumes, though it's possible to do so, complicating matters
   somewhat more.

   The first partition is /boot, the second is /.  I didn't use logical
If you want to extract the filesystems, I'd recommend using lomount as Ian suggests (and then just tar up the partitions).

Sure.  Diff'rent strokes for diff'rent folks...[1]


5. Loopback mount the qemu images, creating a couple of mountpoints.
   Using the file I'm referencing above (rhel4):

       mkdir mp1 mp2
       su -c 'mount -o loop,offset=$(( 63 * 512 )) -t ext3 rhel4 mp1'
su -c 'mount -o loop,offset=$(( 4192964 * 512 )) -t ext3 rhel4 mp2'

As a final step, you could copy the contents of these two mountpoints
into a partition or a single filesystem image (a file with just a
filesystem in it, no partitions) which can be used for a Xen file-backed
DomU, etc.


There's a few things you'll want to do once you do the QEMU install. Namely, you'll want to make sure to install the appropriate modules (and run depmod).

Which modules?

I'm running RHEL4 and after /etc/fstab, relocating boot and modifying /etc/fstab, commenting out the MAC address, it seems happy.


Otherwise, it just works.

The next logical step is to run QEMU within a domU and automate the whole process.

Actually, a decent RH bootstrap would be useful. Dittos the ability to install into an arbitrary target, *without* requiring a valid bootable partition.

See RH Bugzilla:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150206
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150946


QEMU is a pretty amazing little piece of software :-)

Innit just?  Spread the word, brother ;-)


Cheers.

--------------------
Notes:

1.  ObGaryColeman, showing my age.  Wait!  I tuned in, but I didn't watch...

--
Karsten M. Self <karsten@xxxxxxxxxxxxx>
XenSource, Inc.
2300 Geng Road #250                                +1 650.798.5900 x259
Palo Alto, CA 94303                                +1 650.493.1579 fax


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users