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

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

 



On Wed, Jun 17, 2015 at 09:43:23AM +0200, Cedric Bosdonnat wrote:
> 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?

Not really - that is still not achieving our goal that users should
not need to details about the hypervisor used when configuring a
sandbox.

The goal is that the CLI args to virt-sandbox should be unchanged,
no matter what libvirt URI is provided. Now of course in the case
of virtualized disks, what appears inside the sandbox could be
differently named - ideally we'd find a way to insulate users from
that aspect too.

In normal Linux there are various symlinks /dev/disk/by-{uuid,id,path}
available which link back to /dev/[sda,vda,hda,etc]. These are created
by udev, but we're not running that. I wonder if we could make use of
that concept though - create /dev/disk/by-tag directory and then in the
cli args we could allow a simple tag. eg

   file:foobar=/path/to/source,format=fmt

and then populate a symlink /dev/disk/by-tag/foobar -> /dev/sda

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]