Hi all,
This looks quite interesting, however I'm confused about the partition
table issue. AFAIK the bootloader takes the first 446 bytes of the first
sector on the partition, and the partition table is the last 64 bytes of
this same sector (a sector being 512 bytes).
Your dd command skips the first 63 sectors of the image.
How does this produce a workable disk image?
Marcus.
Anthony Liguori wrote:
> Karsten M. Self wrote:
>
>>>>>
>>>>> 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.
>
>
> It's pretty straight forward to write a program to split a partitioned
> file into multiple single partition images. I'm not sure it's the right
> use case though.
>
>>> 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?
>
>
> No. This is a partitioned file. Xen will expose any file as a straight
> block device under any device number. If you use the device number for
> a whole disk (in this case, hda--although hdb, sda, etc. would also
> work), linux will read the partition table during bootup (that is, the
> first 63 sectors of the disk) and create the appropriate partitions.
>
> To reiterate, FC4.img is an unmodified QEMU raw device. Furthermore,
> with qemu-img convert, you could convert a VMWare image to a QEMU raw
> image, and boot that directly in Xen using this method.
>
>>> 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?
>
>
> Depends on your domU config I guess. FC4 won't boot for me unless it
> finds a modules.dep for the appropriate kernel.
>
>>> 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.
>
>
> With QEMU + VNC under a domU, you can actually install directly into a
> domU I posted a link to a script to build a ramdisk that contains
> QEMU/VNC specifically for this purpose.
>
>>>
>>> QEMU is a pretty amazing little piece of software :-)
>>
>>
>>
>> Innit just? Spread the word, brother ;-)
>
>
> We could definitely improve our collaboration with QEMU. There's a lot
> of cool things you can do when you combine QEMU and Xen.
>
> Regards,
>
> Anthony Liguori
>
>>
>> Cheers.
>>
>> --------------------
>> Notes:
>>
>> 1. ObGaryColeman, showing my age. Wait! I tuned in, but I didn't
>> watch...
>>
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home