All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Wei Liu <Wei.Liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: 4.7 qemu regression: HVM guests fail to boot from xvda
Date: Wed, 8 Jun 2016 11:23:47 +0100	[thread overview]
Message-ID: <5757F233.6050500@citrix.com> (raw)
In-Reply-To: <22359.61702.816424.279071@mariner.uk.xensource.com>

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@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2016-06-08 10:23 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-30 20:42 4.7 qemu regression: HVM guests fail to boot from xvda Olaf Hering
2016-05-31 11:02 ` George Dunlap
2016-05-31 11:16   ` Olaf Hering
2016-05-31 11:32     ` George Dunlap
2016-05-31 11:41       ` Olaf Hering
2016-05-31 12:00         ` George Dunlap
2016-05-31 12:04           ` Olaf Hering
2016-06-01 13:17             ` Olaf Hering
2016-06-01 21:40               ` Olaf Hering
2016-06-02 11:49                 ` Wei Liu
2016-06-02 12:06                   ` Olaf Hering
2016-05-31 12:15           ` Jan Beulich
2016-06-01  9:48           ` Wei Liu
2016-06-01 13:34             ` Olaf Hering
2016-06-01 14:11               ` Wei Liu
2016-06-01 14:32                 ` Olaf Hering
2016-06-01 15:36           ` Ian Jackson
2016-06-03 10:13             ` George Dunlap
2016-06-03 11:20               ` Olaf Hering
2016-06-03 11:27                 ` George Dunlap
2016-06-03 11:45                   ` Ian Jackson
2016-06-06 10:39                     ` George Dunlap
2016-06-06 10:52                       ` Ian Jackson
2016-06-06 11:43                         ` George Dunlap
2016-06-06 12:49                     ` George Dunlap
2016-06-07 14:08                     ` George Dunlap
2016-06-07 14:27                       ` Olaf Hering
2016-06-08 10:17                       ` Ian Jackson
2016-06-07 19:06                     ` Olaf Hering
2016-06-08 10:18                       ` Ian Jackson
2016-06-08 10:23                         ` George Dunlap [this message]
2016-06-08 10:30                           ` Ian Jackson
2016-06-08 10:49                             ` George Dunlap
2016-06-08 11:13                               ` Olaf Hering
2016-06-08 15:56                                 ` Konrad Rzeszutek Wilk
2016-06-03 11:50                   ` Olaf Hering
2016-05-31 12:10       ` Jan Beulich
2016-05-31 13:41         ` George Dunlap
2016-05-31 14:10           ` Jan Beulich
2016-05-31 16:15     ` Konrad Rzeszutek Wilk
2016-06-08 11:38 ` Wei Liu
2016-06-08 12:04   ` Olaf Hering
2016-06-08 12:09     ` Wei Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5757F233.6050500@citrix.com \
    --to=george.dunlap@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=Wei.Liu2@citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=olaf@aepfle.de \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.