Re: [libvirt] [sandbox PATCH 2/3] Add configuration object for disk support

Hi Daniel, On Thu, 2015-06-11 at 14:47 +0100, Daniel P. Berrange wrote: > On Wed, Jun 10, 2015 at 01:40:09PM +0200, Eren Yagdiran wrote: > > Add the config gobject, functions to store and load the new configuration > > fragments and test. This will allow creating sandboxes with attached > > disk with a parameter formatted like file:hda=/source/file.qcow2,format=qcow2 > > > +/** > > + * gvir_sandbox_config_add_disk_strv: > > + * @config: (transfer none): the sandbox config > > + * @disks: (transfer none)(array zero-terminated=1): the list of disks > > + * > > + * Parses @disks whose elements are in the format TYPE:TARGET=SOURCE,FORMAT=FORMAT > > + * creating #GVirSandboxConfigMount instances for each element. For > > + * example > > + * > > + * - file:hda=/var/lib/sandbox/demo/tmp.qcow2,format=qcow2 > > + */ > > One of the goal of the libvirt sandbox code is to insulate apps from > needing to know hypervisor specific differences. The guest side disk > device name is one such big difference. Many hypervisors, including > kvm, will not even honour requested names - you just get whatever > name the guest decides to give you. Essentially the only thing that > libvirt guarantees is the disk ordering. ie if you configure two > disks one with hda and one hdb, libvirt will ensure hda appears > before hdb on the bus or controller. > > So I don't think we should include the target device name in our > configuration syntax here. We should just document that disks > will be added to the guest in the same order that you supply > them to virt-sandbox command line in. The actual device names > will vary according to the hypevisor and guest os. Right. But I think we then need to ask for the bus type then, so that we know whether we'll have ide, scsi or whatever. Then we could have the option like: file:ide=/path/to/source,format=fmt And of course document that the disks will be added in the same order. Does it sound better for you?