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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 08/06/16 11:18, Ian Jackson wrote:
> Olaf Hering writes ("Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to 
> boot from xvda"):
>> 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".
> 
> I'm afraid I think this way lies madness.  You are suggesting that the
> default for hdtype= should depend in a complicated way on the set of
> disk vdevs.  (It also makes hotplug very confusing.)
> 
>>> 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.
> 
> This is a strange use of the phrase "backward compatible".  What you
> mean is that the necessary domU.cfg changes are backward compatible.
> 
>>> 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?
> 
> Maybe.
> 
>> It has to be noted that libvirt does not seem to know about the hdtype=
>> knob, which was introduced in xen-4.6.
> 
> Anyway, to conclude: it seems that you don't like any of my other
> options.  I don't like your suggestion.  But you seem happy with my
> option (1), above.
> 
> Personally I prefer George's suggestion:
>   What about a per-disk property, emulate={default,always,only}

We could consider at an xl level having a domain-wide and system-wide
defaults.  That way Olaf could set "disk_emulate_default=always" (or
whatever) in the global xl.conf and everything would work the way it
used to without even needing to change individual guest config files.

 -George

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