Hi all,
Imagine the following situation, you have :
- one ISCSI storage server providing : lun0 and lun1
- the lun0 and lun1 contains a standard installation of Fedora : VM1 and VM2
- the standards installations define two VG VolGroup00 ...
We didn't define LogicalVolume on the node and we attached directly the
iSCSI
lun to the VM without making partition or LV in Ovirt.
On the node that run VM1 and VM2 you have lun0 and lun1 seen as /dev/sda and
/dev/sdb, but when you run vgscan it hangs, because you have conflict and the
local LVM try to manage "virtual LVM".
When you refresh a iSCSI pool, Ovirt add a task to taskomatic that ask a node
to launch a vgscan, vgscan hang and the pool is never refreshed.
In fact the lun is seen as PV in the VM and for the node, but the version of
LVM running on the node and the VM is not always the same.
You have a conflict between the LVM instance of the lun0 and the local lvm of
your node.
This situation gave to us a lot of desease with the disk access of our VMs.
Do you see a solution to isolate lun containing LVM from the node LVM
instance. It could be possible to filter the iSCSI devices in
/etc/lvm/lvm.conf, but it would be difficult to continue to manage LVM volume
on iSCSI lun and excluding them.
The easiest way to fix it, would be to remove the capicity of doing lvm
action on the node. We use one iSCSI lun for each VM and didn't need the
ability to share the storage space of a lun between VM. I think that a choice
should be done, between a lun managed directly by the VM and a lun shared
between VM with Ovirt, because trying to keep both will produce weird
interaction...
--
Pierre-Gilles Mialon
Responsable h?bergement :: Head of Hosting services
pmialon at linagora.com :: +33.1 58 18 65 46
Linagora :: http://www.linagora.com
27 rue de Berri :: 75008 PARIS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL:
<http://listman.redhat.com/archives/ovirt-devel/attachments/20091016/5ed8cb7a/attachment.sig>
