From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJtgq-0003FL-4j for qemu-devel@nongnu.org; Thu, 25 Jun 2009 14:28:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJtgl-0003DA-MZ for qemu-devel@nongnu.org; Thu, 25 Jun 2009 14:28:51 -0400 Received: from [199.232.76.173] (port=52579 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJtgl-0003D7-FD for qemu-devel@nongnu.org; Thu, 25 Jun 2009 14:28:47 -0400 Received: from mx20.gnu.org ([199.232.41.8]:15186) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MJtgl-0007n3-14 for qemu-devel@nongnu.org; Thu, 25 Jun 2009 14:28:47 -0400 Received: from mail-pz0-f185.google.com ([209.85.222.185]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJtgk-0002vM-Ca for qemu-devel@nongnu.org; Thu, 25 Jun 2009 14:28:46 -0400 Received: by pzk15 with SMTP id 15so1269174pzk.4 for ; Thu, 25 Jun 2009 11:28:44 -0700 (PDT) Message-ID: <4A43C1D8.1000100@codemonkey.ws> Date: Thu, 25 Jun 2009 13:28:40 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] drive_add vs. pci_add References: <4A431D3D.2040604@web.de> <4A439A15.5040707@redhat.com> <200906251702.44505.paul@codesourcery.com> In-Reply-To: <200906251702.44505.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Jan Kiszka , qemu-devel@nongnu.org, Avi Kivity Paul Brook wrote: > On Thursday 25 June 2009, Avi Kivity wrote: > >> On 06/25/2009 09:46 AM, Jan Kiszka wrote: >> >>> Hi, >>> >>> sorry, it's still early, but isn't the monitor command 'drive_add' >>> completely redundant to 'pci_add ... storage'? If yes, and drive_add is >>> only there for legacy users, I would mask its help from the monitor >>> interface to avoid confusion. >>> >> What we really want is pci_add storage to add a storage controller, and >> drive_add to attach a drive to that controller. I don't think that's >> what happens now. >> > > Part of the problem is that we don't currently isolate configs for different > pats of the device stack. There are several different layers at which hotplug > can occur: > > - Device - e.g. PCI hotplug. If done properly this shouldn't care whether > you're adding a NIC, VGA, SCSI HBA, or whatever. > - Drive - Adding/removing drives to an existing HBA. > - Media - e.g. changing the contents of a CDROM drive. > Also, we probably want to separate the definition of storage from the act of connecting the storage via hotplug. If I were going to add new monitor commands today, I may do something like: # Create a new BlockDriverState with a symbolic name of 'Foo' (qemu) storage_add Foo file=/path/to/image,snapshot=on # Create a new pci device with a symbolic name of 'Bar' (qemu) pci_create dev=virtio-blk,name=Bar # Connect the storage backend Foo to the storage frontend Bar (qemu) storage_connect Foo Bar # Attach PCI device via hotplug (qemu) pci_hotplug Bar addr=0.01.0 Beyond pci_hotplug, you could also introduce pci_insert/remove commands. This could be used if starting a guest in the stopped state to insert a PCI card or in combination with -no-shutdown. For attaching SCSI disks, you would probably introduce something like: # Create a new scsi-disk named Bar (qemu) scsi_create_lun target=0,lun=1,name=Bar # Connect Foo storage backend to Bar storage frontend (qemu) storage_connect Foo Bar # Attach lun 'Bar' to existing SCSI controller named 'Controller' (qemu) scsi_attach_lun Bar Controller Regards, Anthony Liguori