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 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 :)
Sign-off-by: Stefan de Konink <dekonink(a)kinkrsoftware.nl>
Stefan
ps. please update the AUTHORS with the above e-mail adress. I try to
migrate all my email from 'personal' to 'work'.