On 03/19/2010 04:44 AM, Nicolas Greneche wrote:
-----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
Are the appropriate network interfaces started/configured?
