qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC]virtio-blk: add disk-name device property


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [RFC]virtio-blk: add disk-name device property
Date: Thu, 12 Jan 2017 14:27:22 +0000
User-agent: Mutt/1.7.1 (2016-10-04)

On Thu, Jan 12, 2017 at 10:22:12AM +0800, Fam Zheng wrote:
> On Thu, 01/12 09:22, Yang Zhang wrote:
> > On 2017/1/4 22:44, Stefan Hajnoczi wrote:
> > > On Tue, Jan 03, 2017 at 10:53:06AM -0600, Eric Blake wrote:
> > > > On 12/29/2016 08:41 PM, Junkang Fu wrote:
> > > > > >From 74e913fc41ea98d1dde692175f1e3fb6729342aa Mon Sep 17 00:00:00 
> > > > > >2001
> > > > > From: "junkang.fjk" <address@hidden>
> > > > > Date: Wed, 24 Aug 2016 19:36:53 +0800
> > > > > Subject: [PATCH] virtio-blk: add disk-name device property
> > > > > 
> > > > > Current virtio-blk disk name(ex. /dev/vdb) has nothing to do with the
> > > > > target dev
> > > > > name specified in libvirt xml file. For example, we may get disk name
> > > > > /dev/vdb in
> > > > > VM while target dev specified in libvirt xml is vdc.
> > > > 
> > > > It's not really libvirt's fault.  The libvirt XML names are for
> > > > convenience, but nothing on the host side requires the guest to pick the
> > > > same naming scheme as the host.
> > > > 
> > > > I guess your proposal is to enhance the virtio spec such that clients
> > > > that are new enough to honor the new addition to the virtio spec will
> > > > change their name-picking algorithm to use the name provided by the
> > > > host, rather than their current approach of picking whatever name they
> > > > feel like, and then enhance libvirt to pass the XML name on down to the
> > > > guest?  It might work, but as others have pointed out, it will require a
> > > > virtio spec change first.
> > > 
> > > This change is unnecessary.  The -device virtio-blk-pci,serial= property
> > > already exists for this purpose.
> > 
> > how about the /dev/vdabc? I guess lots of people prefer to use it instead of
> > /dev/disk/by-id/xxx?
> 
> I disagree. Using /dev/sdX has exactly the same issue and that's why fstab and
> boot loader etc almost always use UUID or disk label by default because they 
> are
> more stable.

Right, /dev/sdX shouldn't be used in configuration files or other
persistent state.

Try cat /etc/fstab on your own system.

On my system there are no /dev/sdX paths in /etc/fstab, only UUIDs and
LVM logical volume paths.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]