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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 31.05.16 at 15:41, <george.dunlap@xxxxxxxxxx> wrote:
> On Tue, May 31, 2016 at 1:10 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 31.05.16 at 13:32, <george.dunlap@xxxxxxxxxx> wrote:
>>> On Tue, May 31, 2016 at 12:16 PM, Olaf Hering <olaf@xxxxxxxxx> wrote:
>>>> On Tue, May 31, George Dunlap wrote:
>>>>
>>>>> On Mon, May 30, 2016 at 9:42 PM, Olaf Hering <olaf@xxxxxxxxx> 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?

Yes.

> Regarding an upgrade: fstab and other tools can be handed UUIDs;

You know how people behave - you tell them "don't use raw
device names" and they still do. (In a few places I'm guilty of this
myself - on kernel command lines, for brevity, I prefer using raw
device names for "root=", but I also know that it's going to be me
to deal with the fallout.)

> and
> an enterprise-grade distribution could probably include udev scripts
> to create symlinks, right?

I guess so. Yet the question is - how would the script know what
symlinks to create? Cross linking between /dev/xvd* and /dev/hd*
(or /dev/sd*) can't be done blindly, as a guest may have e.g. both
xvda and hda specified in its config file (which works with the old
blkfront afaict, but wouldn't work with upstream's).

Jan


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