On Thu, 15 May 2008, Daniel P. Berrange wrote: > On Thu, May 15, 2008 at 03:20:06PM +0200, Stefan de Konink wrote: > > On Thu, 15 May 2008, Stefan de Konink wrote: > > > > > Now I wonder, is it possible to have here > > > somethinglike storage://netapp/lun-0? > > > > > > > [snip] > > > > > From the standpoint: we make it easy for the user I would prefer not to > > > provide a Linux specific path. > > > > http://libvirt.org/formatdomain.html#elementsDisks > > > > I propose an extension to the current <source> tag specifying where a disk > > should come from. In my humble opinion something that is already available > > inside libvirt should be reused. > > > > Therefore: > > > > source > > If the disk type is "file", then the file attribute specifies the > > fully-qualified path to the file holding the disk. If the disk type is > > "block", then the dev attribute specifies the path to the host device to > > serve as the disk. > > > > If the disk type is "pool", then the pool attribute and the volume > > attibute specify what volume should be used for this disk. > > I'd support a syntax like this: > > <disk type="pool"> > <source pool="myfiler" vol="lun-4"/> > <target dev="xvda"/> > </disk> I understand your point :) Nevermind, I think you are right, making a CD that is backed by a LUN is non-sence anyway. > > I'm currently playing with xml.c to get it supported. One thing > > that would be interesting is a 'start' parameter, so when the > > pool is defined but not yet started it should start. Any comments > > to the idea? > > No, lifecycle changes in one object (the domain) should not effect lifecycle > changes on another (the storage). We already provide ability for pools to > be auto-started at time libvirtd starts. Pools will typically be serving more > than one guest anyway, so starting a pool upon starting a domain is a niche > use case. Management tools can provide policy such as auto-starting pools > in this scenario if desired. Expect a RFC patch soon ;) Stefan -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list