Hi, We have an oVirt Platforme using the 4.1 version. when the platforme was installed, it was made of : - Two HP Proliant DL380 G9 as hypervisors - One HP MSA1040 for iSCSI - One Synology for NFS - Two switches, one for network/vm traffic, the second for storage traffic. The problem : the hosted-engine domain was created using iSCSI on the HP MSA. The problem is that this disk array does not give the possibility to create different targets, it presents just one target. At that time we create both the hosted-engine and the first data domain using the same target, and we didn't pay attention to the information saying "i*f you are using iSCSI storage, do not use the same iSCSI target for the shared storage domain and data storage domain*". Question : - what problems can be generated by this (mis-)configuration? - Is this a must to do (correct) configuration. Regards.
I had this situation a while back. As I recall ovirt has no way to selectivity un-mount devices exposed via an iSCSI target. So the problem you could hit is that if you tried to put your data domain into maintenance it would nuke any other domains that are accessed through that target (e.g. your hosted-engine domain). For me the situation was even worse as I was doing boot-from-SAN as well. So I would loose the boot disk. On my NetApp I ended up creating three targets: BFS, hosted-engine & data. ---- On Mon, 28 Oct 2019 11:27:53 +0000 wodel youchi <mailto:wodel.youchi@gmail.com> wrote ---- Hi, We have an oVirt Platforme using the 4.1 version. when the platforme was installed, it was made of : - Two HP Proliant DL380 G9 as hypervisors - One HP MSA1040 for iSCSI - One Synology for NFS - Two switches, one for network/vm traffic, the second for storage traffic. The problem : the hosted-engine domain was created using iSCSI on the HP MSA. The problem is that this disk array does not give the possibility to create different targets, it presents just one target. At that time we create both the hosted-engine and the first data domain using the same target, and we didn't pay attention to the information saying "if you are using iSCSI storage, do not use the same iSCSI target for the shared storage domain and data storage domain". Question : - what problems can be generated by this (mis-)configuration? - Is this a must to do (correct) configuration. Regards. _______________________________________________ Users mailing list -- mailto:users@ovirt.org To unsubscribe send an email to mailto:users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/MSGB3DK6L4OE6I...
Hello I am going to deploy in field an Hosted Engine oVirt environment with just one Storage (just one Target ID) and 6 Blades that access to the Storage by iSCSI. Even I did not read the Warning about the requirement of a double target ID, one for the LUN of the Engine and another one for the LUNs that host the Disks of the other VMs, and change the Bill of Material now, it is a bit complicated ! After the reading of this thread I set up, in Lab, a test environment in which 2 Servers run the oVirt Node 4.3.7 and they host the Engine in version 4.3.7, too A third Server runs a CentOS version 7.x and it has been configured to export Disk space by iSCSI (targetcli tool). On the STorage Emulator I have configured 3 LUNs behind the same Target ID. On the oVirt Environment I have 1 DC and 1 Cluster including the 2 Servers and 3 Storage Domains corresponding to teh 3 LUNS. The Cluster configured is the Default one, i.e. the one on which it runs the Hosted Engine. On the same Cluster I have run 2 VMs with CentOS guest. Now the Engine keeps its data on the first LUN, one of the guest OS keeps its data on the second LUN and the second guest OS keeps its data on the third LUN. Well, if I put in Maintenance one of the guest OS LUN, the other LUNs (the one of the second guest OS and the one of the Engine) continues to be available. I wonder if there is any other reason that requires the presence of a second Storage in the network design, or if we con consider it just as a preferred design but not as Mandatory. Many thanks, Luca
participants (3)
-
Alan -
luca.gazzi＠italtel.com -
wodel youchi