[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to boot from xvda



On Fri, Jun 03, Ian Jackson wrote:

> There are two problems with this `hdtype' approach.
> 
> Firstly, it is global.  That is, it applies to all disks of the
> particular guest.  But then maybe we don't care about that because
> this anomalous major-number-stealing behaviour is probably per-guest
> rather than per-disk.

I think there is no issue with hdtype being a global knob. The
controller type for disks is either piix or ahci.

> Secondly, the proposal above involves changing both the semantics of
> existing `hdtype' parameter values, and the default hdtype value.  The
> resulting situation would be that even specifying vdev=hda wouldn't
> get you an emulated device, by default, unless you specified `hdtype'
> too.  I don't think that is right.

IMO vdev= should influence hdtype= if it is unset. Just to make sure the
emulated disk with vdev=xvd can be achived with existing config knobs.

I think the situation was like this in xen-4.6:
a) no hdtype=,  vdev=hd   results in an emulated piix controller
b) no hdtype=,  vdev=xvd  results in an emulated piix controller
c) hdtype=ide,  vdev=hd   results in an emulated pixx controller
d) hdtype=ide,  vdev=xvd  results in an emulated piix controller
e) hdtype=ahci, vdev=hd   results in an emulated ahci controller
f) hdtype=ahci, vdev=xvd  results in an emulated ahci controller

Each of the above was bootable because the disk was visible to the BIOS.
It was possible to mix hd and xvd for disks as long as the index
(a,b,c,..) is unique.

With xen-4.7 any of the vdev=xvd results in a non-booting guest.
So something has to be changed in domU.cfg anyway.
Currently its like this:
a) no hdtype=,  vdev=hd   results in an emulated piix controller
b) no hdtype=,  vdev=xvd  results in PV-only disk
c) hdtype=ide,  vdev=hd   results in an emulated pixx controller
d) hdtype=ide,  vdev=xvd  results in PV-only disk
e) hdtype=ahci, vdev=hd   results in an emulated ahci controller
f) hdtype=ahci, vdev=xvd  results in PV-only disk

This could be added:
hdtype=ide and vdev=xvd gives an emulated piix controller
hdtype=ahci and vdev=xvd gives an emulated ahci controller

To achieve this the default hdtype= should become "UNSET", and a vdev=hd
should set it to IDE if it was "UNSET". That means there could be yet
another state "PVONLY".

As a result the possible configs in xen-4.7 are liks this:
a) no hdtype=,  vdev=hd   results in an emulated piix controller
b) no hdtype=,  vdev=xvd  results in PV-only disk
c) hdtype=ide,  vdev=hd   results in an emulated pixx controller
d) hdtype=ide,  vdev=xvd  results in an emulated piix controller
e) hdtype=ahci, vdev=hd   results in an emulated ahci controller
f) hdtype=ahci, vdev=xvd  results in an emulated ahci controller
g) hdtype=pv,   vdev=hd   results in PV-only disk
h) hdtype=pv,   vdev=xvd  results in PV-only disk

Existing domU.cfg with variant b) have to be changed to d) to get them
boot again, or rather connect the disks to an emulated controller.
I'm not sure if case g) and h) are really needed.

In my testing with xen-4.6 using hdtype=ahci resulted in no unplug, so I
think ahci was really just for emulated usage. Perhaps the pvops kernel
does a more complete unplug? I have not tested ahci with xen-4.7.

> The possibilities I see are:
> 
> (1) New boolean per-guest parameter for this behaviour, meaning
>    `provide emulated devices for all xvd* as if they were hd*'.

This would be an backward compatible approach, at least domU.cfg will
work with older toolstack. libvirt needs to know about this.

> (2) New `hdtype=ideforpv' which has the same effect as `hdtype=ide'
>    plus the semantics in (1) above.  (I'm open to better naming
>    suggestions.)

This would be an incompatible change, older toolstacks dont know the
value.

> (3) New disk property parameter `hvm-emulate' in the Deprecated
>     section of xl-disk-configuration.txt.

This would be an incompatible change, older toolstacks dont know the
value.

> Open questions:
> 
> Do we also need `... as if they were sd*' or `provide ide emulated
> devices where vdev=sd* is specified?'

sd results in an emulated LSI SCSI controller.

> If we have `hdtype=ideinclpv' do we also need `hdtype=ahciinclpv' ?

I think that is not needed given that there is no unplug (in my
testing).

> What should happen if these options are enabled for PV guests - should
> they be silently ignored, or should they be rejected ?

IMO no. Do we have such rejects already for PV or HVM only options?


It has to be noted that libvirt does not seem to know about the hdtype=
knob, which was introduced in xen-4.6.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.