-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave Allan wrote:
On 03/17/2010 06:38 AM, Nicolas Greneche wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Former user of Xen and newbie in kvm/qemu/libvirt stuff, I give it a try on my network ;-)
I need to run a VM with iSCSI target attached.
I did it this way :
1) Creation of iscsi pool (equa.xml) :
<pool type="iscsi"> <name>equalog</name> <source> <host name="10.10.0.1"/> <device path="iqn.2001-05.com.equallogic:0-8a0906-4992c7f05-39c000000114b8fc-vglog"/>
</source> <target> <path>/dev/disk/by-path</path> </target> </pool>
This pool start smoothly (when open-iscsi started), no problems. An entry is created in /dev/disk/by-path/ related to iscsi target.
2) I flagged it autostart :
root@sandi:~# virsh pool-autostart equalog Pool equalog marked as autostarted
root@sandi:~# virsh pool-list Name State Autostart - ----------------------------------------- equalog active yes
3) In my guest VM, I have following section :
<disk type='block' device='disk'> <driver name='qemu'/> <source dev='/dev/disk/by-path/ip-10.10.0.1:3260-iscsi-iqn.2001-05.com.equallogic:0-8a0906-4992c7f05-39c000000114b8fc-vglog-lun-0'/>
<target dev='vdc' bus='virtio'/> <alias name='virtio2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </disk>
When I start VM, iscsi target is availaible.
The snag is that when I reboot the host, the pool is not automatically started (making it impossible to autostart VM relying on this iscsi volume).
I verified that open-iscsi is started first. Startup script is localised in /etc/rcS.d which is prior to /etc/rc2.d (my default runlevel). Libvirtd is started in rc2.d and not mentionned in rcS.d.
My questions are : - - Is this the correct way to attach iscsi volume to a guest ? - - Did I missed something to have iscsi pool autostart working at boot time ?
You're doing everything right, so it's odd that the pool isn't autostarting. Does the pool autostart properly if you restart libvirtd when the system is fully booted?
Dave
Hi Dave, It's a very odd problem. Making network debugging with tcpdump makes me see that my network stack doesn't receive "arp reply" related to my target. If I add an ARP entry by hand in cache or a sleep just before libvirtd start function in startup script it works like a charm. Very odd, I asked debian package maintainers for help : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574358 Regards, - -- Nicolas Greneche - RSSI et Sysadmin Centre de Ressources Informatiques (CRI) Doctorant au sein du projet SDS - www.sds-project.fr Mail : nicolas.greneche_(at)_univ-orleans.fr GPG : http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5FEBD0EF Universite d'Orleans Web : http://blog.garnett.fr Batiment 3IA - 2e etage Tel : 02 38 49 25 26 6 rue Leonard de Vinci BP 6102 45061 ORLEANS Cedex 2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkujOVAACgkQTx/Y+1/r0O8k7gCcCKYqVEzuhBnEzR3ykvCUcBEs uesAoJa+3hi3mEiANIQyBbM08ghrTUIs =RF1o -----END PGP SIGNATURE-----