On Wed, Jun 08, 2016 at 01:13:03PM +0200, Olaf Hering wrote:
> On Wed, Jun 08, George Dunlap wrote:
>
> > We definitely don't want to be putting this new stuff we're discussing
> > in 4.7.0. I'd be OK with reverting the original change for the release.
>
> I'm fine with delaying a change to addr
On Wed, Jun 08, 2016 at 02:04:45PM +0200, Olaf Hering wrote:
> On Wed, Jun 08, Wei Liu wrote:
>
> > I think we should just revert the patch in question and solve this issue
> > properly in 4.8.
>
> What impact does reverting c0c099d have for OVMF?
> I dont know myself, just used it the first time
On Wed, Jun 08, Wei Liu wrote:
> I think we should just revert the patch in question and solve this issue
> properly in 4.8.
What impact does reverting c0c099d have for OVMF?
I dont know myself, just used it the first time now with staging-4.6.
Olaf
_
I had the impression that Olaf was fine with just updating the
documentation so I dropped this thread from my radar. But Ian brought my
attention to it again because there is discussion on detailed API
design, which is bad at this stage of a release.
I think we should just revert the patch in ques
On Wed, Jun 08, George Dunlap wrote:
> We definitely don't want to be putting this new stuff we're discussing
> in 4.7.0. I'd be OK with reverting the original change for the release.
I'm fine with delaying a change to address the (theoretical) breakage
introduced by c0c099d.
What I just learne
On 08/06/16 11:30, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] 4.7 qemu regression: HVM guests fail
> to > 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.con
George Dunlap writes ("Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to
> 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
> use
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
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
George Dunlap writes ("Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to
boot from xvda"):
> In every part of the whole system -- in dom0, in the guest, in
> everything -- I use xvda; *except* in the parts dealing with the guest
> config, where for some reason I my
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
On Tue, Jun 07, George Dunlap wrote:
> In every part of the whole system -- in dom0, in the guest, in
> everything -- I use xvda; *except* in the parts dealing with the guest
> config, where for some reason I mysteriously put 'hda', which ends up
> producing an xvda either when booted PV or when b
On 03/06/16 12:45, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] 4.7 qemu regression: HVM guests fail
> to boot from xvda"):
>> On 03/06/16 12:20, Olaf Hering wrote:
>>> I think the regression is: 'vdev=xvda' does not result in a disk
>>
On 03/06/16 12:45, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] 4.7 qemu regression: HVM guests fail
> to boot from xvda"):
>> On 03/06/16 12:20, Olaf Hering wrote:
>>> I think the regression is: 'vdev=xvda' does not result in a disk
>>
On 06/06/16 11:52, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] 4.7 qemu regression: HVM guests fail
> to boot from xvda"):
>> On 03/06/16 12:45, Ian Jackson wrote:
>>> Secondly, the proposal above involves changing both the semantics of
>>>
George Dunlap writes ("Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to
boot from xvda"):
> On 03/06/16 12:45, Ian Jackson wrote:
> > Secondly, the proposal above involves changing both the semantics of
> > existing `hdtype' parameter values, and
On 03/06/16 12:45, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] 4.7 qemu regression: HVM guests fail
> to boot from xvda"):
>> On 03/06/16 12:20, Olaf Hering wrote:
>>> I think the regression is: 'vdev=xvda' does not result in a disk
>>
On Fri, Jun 03, George Dunlap wrote:
> I'd be OK with this. But is the "hdtype unset" also available at the
> libxl level?
Yes, it could. Right now the .idl sets it to IDE. Looks like another
enum has to be added and announced via a #define.
> Although I still think that the XenoLinux kernels s
George Dunlap writes ("Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to
boot from xvda"):
> On 03/06/16 12:20, Olaf Hering wrote:
> > I think the regression is: 'vdev=xvda' does not result in a disk
> > connected to the emulated controller. Should we ch
On 03/06/16 12:20, Olaf Hering wrote:
> On Fri, Jun 03, George Dunlap wrote:
>
>> On 01/06/16 16:36, Ian Jackson wrote:
>>> I think we should fix this with a syntax for explicitly specifying a
>>> pv-only device with the hd* pv block number.
>
>> Would this be a suitable solution for you, and do
On Fri, Jun 03, George Dunlap wrote:
> On 01/06/16 16:36, Ian Jackson wrote:
> > I think we should fix this with a syntax for explicitly specifying a
> > pv-only device with the hd* pv block number.
> Would this be a suitable solution for you, and do you think you
> understand the suggestion well
On 01/06/16 16:36, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] 4.7 qemu regression: HVM guests fail
> to boot from xvda"):
>> On Tue, May 31, 2016 at 12:41 PM, Olaf Hering wrote:
>>> I think if some domU.cfg for xen-4.3+ has 'vdev=xvd*&#x
On Thu, Jun 02, Wei Liu wrote:
> On Wed, Jun 01, 2016 at 11:40:51PM +0200, Olaf Hering wrote:
> > tool_ver vdev_str qemu format usable bootable
> > xen-4.5 xvd qmain qcow2 yes SUSE:no, staging:yes
> What does "staging" mean?
That should have been staging-4.5.
Some change bet
On Wed, Jun 01, 2016 at 11:40:51PM +0200, Olaf Hering wrote:
> On Wed, Jun 01, Olaf Hering wrote:
>
> > Here is a list. Essentially it means that upgrading dom0 to xen-4.7
> > might break existing domU if they happen to use xvd* in domU.cfg:
>
> Actually the list goes like shown below after some
On Wed, Jun 01, Olaf Hering wrote:
> Here is a list. Essentially it means that upgrading dom0 to xen-4.7
> might break existing domU if they happen to use xvd* in domU.cfg:
Actually the list goes like shown below after some real testing.
Now sure why xvd/qemu-xen/raw|qcow2 fails with our 4.5.2 ba
George Dunlap writes ("Re: [Xen-devel] 4.7 qemu regression: HVM guests fail to
boot from xvda"):
> On Tue, May 31, 2016 at 12:41 PM, Olaf Hering wrote:
> > I think if some domU.cfg for xen-4.3+ has 'vdev=xvd*' and the domU uses
> > for some reason kernel names
On Wed, Jun 01, Wei Liu wrote:
> > Konrad mentioned Solaris, no idea if its frontend driver uses the vdev
> > string. BSD should be checked as well.
> >
>
> So you are fine with documenting without reverting the patch?
I think yes, If Solaris and BSD domU are not affected by the change.
Given t
On Wed, Jun 01, 2016 at 03:34:08PM +0200, Olaf Hering wrote:
> On Wed, Jun 01, Wei Liu wrote:
>
> > So I think the safest option now is to revert the said patch and figure
> > out what to do next.
>
> What did OSStest report when c0c099d got into the tree? Do these test
> domU.cfg files contain v
On Wed, Jun 01, Wei Liu wrote:
> So I think the safest option now is to revert the said patch and figure
> out what to do next.
What did OSStest report when c0c099d got into the tree? Do these test
domU.cfg files contain vdev=hd instead of vdev=xvd, so the boot breakage
was not noticed?
What are
On Tue, May 31, Olaf Hering wrote:
> On Tue, May 31, George Dunlap wrote:
>
> > Do you have a concrete proposal?
>
> I have to give it some more thought what the impact really is, what
> config variants are affected.
Here is a list. Essentially it means that upgrading dom0 to xen-4.7
might brea
On Tue, May 31, 2016 at 01:00:45PM +0100, George Dunlap wrote:
> On Tue, May 31, 2016 at 12:41 PM, Olaf Hering wrote:
> > On Tue, May 31, George Dunlap wrote:
> >
> >> Sorry, can you expand on this a bit? Are you saying that on SuSE, if
> >> you specify "vdev=xvda" in your config file, that you'l
On Tue, May 31, 2016 at 01:16:14PM +0200, Olaf Hering wrote:
> On Tue, May 31, George Dunlap wrote:
>
> > On Mon, May 30, 2016 at 9:42 PM, Olaf Hering wrote:
> > > With staging-4.6 this domU boots from xvda, qemu creates an emulated
> > > disk. With staging no disk is found, unless the name is ch
>>> On 31.05.16 at 15:41, wrote:
> On Tue, May 31, 2016 at 1:10 PM, Jan Beulich wrote:
> On 31.05.16 at 13:32, wrote:
>>> On Tue, May 31, 2016 at 12:16 PM, Olaf Hering wrote:
On Tue, May 31, George Dunlap wrote:
> On Mon, May 30, 2016 at 9:42 PM, Olaf Hering wrote:
> > Wi
On Tue, May 31, 2016 at 1:10 PM, Jan Beulich wrote:
On 31.05.16 at 13:32, wrote:
>> On Tue, May 31, 2016 at 12:16 PM, Olaf Hering wrote:
>>> On Tue, May 31, George Dunlap wrote:
>>>
On Mon, May 30, 2016 at 9:42 PM, Olaf Hering wrote:
> With staging-4.6 this domU boots from xvda,
>>> On 31.05.16 at 14:00, wrote:
> Really 'vdev' string in the the guest config file is only meant to
> tell libxl how it should behave -- it should ideally not have any
> effect on what devices you see in the backend. And furthermore, it
> seems to me that when Linux upstream rejected the idea o
>>> On 31.05.16 at 13:32, wrote:
> On Tue, May 31, 2016 at 12:16 PM, Olaf Hering wrote:
>> On Tue, May 31, George Dunlap wrote:
>>
>>> On Mon, May 30, 2016 at 9:42 PM, Olaf Hering wrote:
>>> > With staging-4.6 this domU boots from xvda, qemu creates an emulated
>>> > disk. With staging no disk i
On Tue, May 31, George Dunlap wrote:
> Do you have a concrete proposal?
I have to give it some more thought what the impact really is, what
config variants are affected.
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-
On Tue, May 31, 2016 at 12:41 PM, Olaf Hering wrote:
> On Tue, May 31, George Dunlap wrote:
>
>> Sorry, can you expand on this a bit? Are you saying that on SuSE, if
>> you specify "vdev=xvda" in your config file, that you'll get PV
>> devices named "/dev/xvda", but that if you specify "vdev=hda"
On Tue, May 31, George Dunlap wrote:
> Sorry, can you expand on this a bit? Are you saying that on SuSE, if
> you specify "vdev=xvda" in your config file, that you'll get PV
> devices named "/dev/xvda", but that if you specify "vdev=hda", that
> you'll get PV devices but named "/dev/hda"?
Yes, t
On Tue, May 31, 2016 at 12:16 PM, Olaf Hering wrote:
> On Tue, May 31, George Dunlap wrote:
>
>> On Mon, May 30, 2016 at 9:42 PM, Olaf Hering wrote:
>> > With staging-4.6 this domU boots from xvda, qemu creates an emulated
>> > disk. With staging no disk is found, unless the name is changed to hd
On Tue, May 31, George Dunlap wrote:
> On Mon, May 30, 2016 at 9:42 PM, Olaf Hering wrote:
> > With staging-4.6 this domU boots from xvda, qemu creates an emulated
> > disk. With staging no disk is found, unless the name is changed to hda.
> > Looks like qemu-2.6 does not handle xvda either.
>
>
On Mon, May 30, 2016 at 9:42 PM, Olaf Hering wrote:
> With staging-4.6 this domU boots from xvda, qemu creates an emulated
> disk. With staging no disk is found, unless the name is changed to hda.
> Looks like qemu-2.6 does not handle xvda either.
This was intentional; see this thread:
https://m
With staging-4.6 this domU boots from xvda, qemu creates an emulated
disk. With staging no disk is found, unless the name is changed to hda.
Looks like qemu-2.6 does not handle xvda either.
Is such setup not part of OSS test, does OSS default to 'vdev=hda'?
Olaf
name="domU"
uuid="64dfa382-6365-4
43 matches
Mail list logo
