[libvirt] Domain XML format using defined storage volume + RFC

[Daniel P. Berrange]

On Thu, May 15, 2008 at 03:58:33PM +0200, Stefan de Konink wrote:
> On Thu, 15 May 2008, Daniel P. Berrange wrote:
> 
> > A storage pool is not just SCSI. It can be a directory of ISO files, an NFS
> > mount of ISO files, local device nodes (including CDROM). So it is perfectly
> > possible that we'll use a pool to back a virtual CD device. This is dealt
> > with by simply specifying the 'device='cdrom' attribute. This shouldn't impact
> > the implementation since the choice of backend storage is completely independant
> > of the type of disk device emulated in the guest. For a CD you'd just use:
> >
> >       <disk type="pool" device="cdrom">
> >         <source pool="myfiler" vol="lun-4"/>
> >         <target dev="hdc"/>
> >       </disk>
> 
> Nevermind, my reading skills are almost as bad as my coding skills. I
> mixed up the type and device attributed. But implemented it directly in
> the type attribute and realised the true meaning of your comment too late.
> 
> The code I produced is still *untested*. It does compile, but I still did
> not define any normal domain with libvirt, and if this works I hope my
> problems are all over.

I generally like code dealing with XML parsing to have test cases defined in
the tests/qemu*test.c files...

> I don't know if you picked up the message about open-iscsi. The
> libopen-iscsi idea was accepted. So technically we can use their functions
> directly never having migrate from one sysfs to another, because 'they'
> fix it. So if the user has a recent version of open-iscsi, they will
> automatically have the right lookup algorithm.
> 
> It might be interesting to 'natively' do the scanning too, without
> invoking the binary. If you want to do this, I'm happy to put all the
> functions we need in one binary and update their Makefile. The iscsi
> dependancy should then check for a recent open-iscsi version.
> 
> Now is this a good idea? For Linux probably... but I hope you can still
> make friends with Solaris guys. I hope they can provide some native
> method too :)

The code is such that we can trivially have multiple backend drivers for
iSCSI if that becomes neccessary. So I've no problem with us providing
one that's based on openiscsi, even if its not (yet) supported on Solaris,
because we can easily drop in an alternate Solaris iSCSI driver as needed.

> Sign-off-by: Stefan de Konink <dekonink at kinkrsoftware.nl>
> 
> ps. please update the AUTHORS with the above e-mail adress. I try to
> migrate all my email from 'personal' to 'work'.

I've changed that.

Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|