Re: 4.7 qemu regression: HVM guests fail to boot from xvda

[George Dunlap <george.dunlap@citrix.com>]

On Tue, May 31, 2016 at 1:10 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 31.05.16 at 13:32, <george.dunlap@citrix.com> wrote:
>> On Tue, May 31, 2016 at 12:16 PM, Olaf Hering <olaf@aepfle.de> wrote:
>>> On Tue, May 31, George Dunlap wrote:
>>>
>>>> On Mon, May 30, 2016 at 9:42 PM, Olaf Hering <olaf@aepfle.de> 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://marc.info/?i=<1444820717-25565-1-git-send-email-anthony.perard@citrix.com>
>>>>
>>>> The idea was to make it possible to create an HVM guest with no
>>>> emulated disks for guest booting with OVMF which contains PV drivers.
>>>
>>> This breaks the domU becasue it changes its device names from 'xvd' to
>>> 'hd' if a xenlinux based kernel is used in domU.
>>> In other words: every SUSE domU out there.
>>
>> 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"?
>
> And just to clarify - this isn't really SUSE-specific, this is how the old
> XenoLinux blkfront has always behaved. In fact when I saw this code
> gone from the upstream (pv-ops) variant, I think I had inquired how
> this is expected to be handling upgrade cases, and I don't think I got
> much of a useful answer to that.

Sure, but I think SuSE are basically the only distribution still using
XenoLinux, right?  Is there actually any open project maintaining the
XenoLinux fork?  If someone wanted to use XenoLinux, wouldn't their
options basically be 1) do all the forward-porting themselves from
some ancient 2.X tree, or 2) use SuSE's port?

Regarding an upgrade: fstab and other tools can be handed UUIDs; and
an enterprise-grade distribution could probably include udev scripts
to create symlinks, right?

The reality is though that the 'vdev=' way of specifying things is a
bit of a mess.  There's no way to specify, "Please make this
emulated-only (i.e., no backing PV drivers)"; there's no way of
hot-plugging in an emulated device; &c &c.

 -George

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