On Tue, Dec 19, 2006 at 12:06:42PM +0100, Henning Sprang wrote:
> Hi Tom,
>
> On 12/18/06, Tom Horsley <tomhorsley@xxxxxxxxxxxx> wrote:
> >[...]
> >Not on my system at work. We installed a 32 bit hvm FC6 on a physical
> >disk via virt-manager, and it worked fine under x86_64 dom0 (also
> >FC6). I did manage to screw it up somehow trying to get the kernel
> >updated, but it was working great before that :-).
>
> Seems I did not explain correctly what I meant.
>
> With what you do, HVM Installs take place exactly not into partitions
> you defined from the outside, but into a block devices, and the hvm
> system then does full partitioning inside this.
Paravirt installs should work in the same way - you are mapping through
virtual disks, not virtual partitions. The latter just happens to work
by chance, and is not supported.
> What I mean what fedora kernels have problems with is when pointing
> the disk config directly onto a partition created from outside the
> domU.
Try mapping your disk through as 'xvda' instead of 'hda1'.
> An example:
>
> In your setup you probably have a disk config line like this;
>
> disk=[ 'phy:/dev/hdb1,hda,w']
>
> What I mean is a setup that look like this:
>
> disk = [ 'phy:/dev/hdb1,hda1,w']
Two issues there
1. We strongly recommend *against* specifying hdX / sdX for virtual disk
device type in paravirt guests. The Xen XVD driver is hijacking the
IDE / SCSI drivers to do this hack. This will not be accepted upstream
and so support will likely disappear in a future kernel-xen release.
Use xvdX instead, eg
'phy:/dev/hdb1,xvda,w'
2. The first form of disk config you have is the preferred setup. ie
map the partition from Dom0, through to DomU as a *disk*, not a
partition. DomU should then partition this further as required,
Your second config 'phy:/dev/hdb1,xvda1,w' may /happen/ to work, but
there are no guarentees this will continue to work in the future.
Only the 'phy:/dev/hdb1,xvda,w' format is supported for compatability
long term.
eg, /dev/hdb1 in Dom0, maps to /dev/xvda in DomU
then DomU can create /dev/xvda1 as needed
By having nested partition tables in this way, you ensure that Dom0
does not see the individual partitions from the DomU. If it were
to see the indiivdual DomU partitions, and say both Dom0 and DomU
have a partition formated ext3 with same label, then mount by label
in Dom0 may end up picking up DomU's partition by accident.
In addition tools in DomU may well get confuse by seeing 'xdva1'
without a corresponding 'xvda'.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
|
