On Tue, Oct 09, 2012 at 10:27:26AM +0800, Dave Young wrote: > On 10/05/2012 04:14 PM, Stefan Hajnoczi wrote: > > > On Sun, Sep 23, 2012 at 10:37:09AM +0800, Dave Young wrote: > >> For the serial number decreasing issue, I think there's only these two > >> ways to > >> select, there's no ideal way to resolve this issue. > >> My use case for this is for the kdump kernel to find proper disks, > >> after 1st kernel crashing 2nd kernel need find right disk to dump vmcore. > >> In this case v1 and v2 aproaches are both find to me. > >> > >> From my point of view, patch v1 is better though, I think unpluging 100000 > >> is > >> not a sane use case. It's not likely to happen. > > > > I'm not sure auto-assigning serial numbers is a good idea. The guest can > > use > > the serial number in /etc/fstab or other places where it expects the serial > > number to be persistent. > > > > Your patch does not provide persistent serial numbers, so a change to the > > QEMU > > invocation could result in different serial numbers. The guest will get > > confused or perhaps refuse to boot. > > > Yes, it introduce confusion, but in this way at least the serial number > can be persistent across guest reboot. Traditionally ide disks use this > way as well, such as QEMU_HARDISK_00001, I think guest should not use > this in /etc/fstab.
If you don't want to set a persistent serial number, use another mechanism to identify the disk. For example, Linux has /dev/disk/by-path/ which identifies virtio-blk PCI adapters, IDE, SCSI disks, etc. Does this work for your use case? Stefan