From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54219) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TK33t-00082O-2I for qemu-devel@nongnu.org; Fri, 05 Oct 2012 04:15:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TK33n-00064g-7g for qemu-devel@nongnu.org; Fri, 05 Oct 2012 04:15:09 -0400 Received: from mail-bk0-f45.google.com ([209.85.214.45]:52756) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TK33n-00062c-0B for qemu-devel@nongnu.org; Fri, 05 Oct 2012 04:15:03 -0400 Received: by mail-bk0-f45.google.com with SMTP id jf3so646679bkc.4 for ; Fri, 05 Oct 2012 01:15:01 -0700 (PDT) Date: Fri, 5 Oct 2012 10:14:59 +0200 From: Stefan Hajnoczi Message-ID: <20121005081458.GC1399@stefanha-thinkpad.redhat.com> References: <20120921133031.GA1682@darkstar.nay.redhat.com> <505C768A.5070801@redhat.com> <20120923023709.GA2742@darkstar.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120923023709.GA2742@darkstar.nay.redhat.com> Subject: Re: [Qemu-devel] [PATCH v2] virtio-blk: add default serial id List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dave Young Cc: Eric Blake , qemu-devel@nongnu.org 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. I'd prefer if we don't expose a temporary serial number at all in order to avoid issues like this. Stefan