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