On Thu, Dec 31, 2009 at 01:03:29PM -0500, Gerry Reno wrote:
> Fajar A. Nugraha wrote:
> >On Thu, Dec 31, 2009 at 1:46 PM, Gerry Reno <greno@xxxxxxxxxxx> wrote:
> >
> >>>At this point it's probably easiest to just create another virtual
> >>>disk with one primary partition, and copy the contents of the original
> >>>/boot there. It's A LOT easier compared to messing up with existing
> >>>partition table. Your domU config should then look something like this
> >>>
> >>>disk = [ "tap:aio:/var/lib/xen/images/CLOUD-CC-1-boot.img,xvda,w",
> >>>"tap:aio:/var/lib/xen/images/CLOUD-CC-1.img,xvdb,w" ]
> >>>
> >>>
> >>If I do this then maybe I can straighten the original partition table out;
> >>remove the last two partitions and create a primary active partition for
> >>/boot.
> >>
> >
> >If you want to use a new disk image for /boot, then yes, the disk
> >image only need one small partition. You can still use LVM from the
> >orginal disk -- no need to migrate/copy that.
> >
> >If you want to modify the existing partition table manually, BE
> >CAREFUL. fdisk uses cylinders as unit by default, so you should switch
> >to sectors. Here's an example:
> >
> ># fdisk -l /dev/xvda
> >
> >Disk /dev/xvda: 10.7 GB, 10737418240 bytes
> >255 heads, 63 sectors/track, 1305 cylinders
> >Units = cylinders of 16065 * 512 = 8225280 bytes
> >
> > Device Boot Start End Blocks Id System
> >/dev/xvda1 1 1000 8032468+ 8e Linux LVM
> >/dev/xvda2 1001 1305 2449912+ 5 Extended
> >/dev/xvda5 * 1001 1305 2449881 83 Linux
> >
> ># fdisk -lu /dev/xvda
> >
> >Disk /dev/xvda: 10.7 GB, 10737418240 bytes
> >255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors
> >Units = sectors of 1 * 512 = 512 bytes
> >
> > Device Boot Start End Blocks Id System
> >/dev/xvda1 63 16064999 8032468+ 8e Linux LVM
> >/dev/xvda2 16065000 20964824 2449912+ 5 Extended
> >/dev/xvda5 * 16065063 20964824 2449881 83 Linux
> >
> >Now if you recreate the partition table using cyulinders as unit, the
> >Linux partition will start on the wrong sector. It will be unusable.
> >However if you use sectors as unit (fdisk -u) you can recreate the
> >partition table to be like this
> >
> ># fdisk -lu /dev/xvda
> >
> >Disk /dev/xvda: 10.7 GB, 10737418240 bytes
> >255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors
> >Units = sectors of 1 * 512 = 512 bytes
> >
> > Device Boot Start End Blocks Id System
> >/dev/xvda1 * 16065063 20964824 2449881 83 Linux
> >/dev/xvda2 63 16064999 8032468+ 8e Linux LVM
> >
> >Partition table entries are not in disk order
> >
> >pygrub can work with that.
> >
> >
>
> The more I thought about this the more I think this is not a distro
> problem. It is a pygrub deficiency and pygrub needs to grow the ability
> to handle these types of partitionings. KVM has no problem booting
> these guests. And even though the partitioning isn't optimal it is
> still valid. We can't go asking distros to modify their valid
> partitioning just to make it 'optimal' for pygrub.
>
Well you could always run it as Xen HVM fully virtualized guest.
That would be pretty close to running it as KVM guest.
If you want to run it as Xen PV (paravirtualized) guest, then you need
to have the disk configuration so that pygrub can work.
-- Pasi
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home