This is more of just a thought or something to pass along to others than anything else. But I think in this course, probably as in any, but I'm finding especially in this one, it is so important to know how to back yourself out of a situation. Something may not be as apparent in the GUI and unlike in other courses where you can drop to the command-line that is not the case here.
If you assign your iSCSI storage domain to the wrong datacenter by mistake, then how do you change that? It is not apparent in the course and if you do not prepare yourself for this and make this mistake when google is not available, then you are stuck.
When you run through the course everything is fine every time and it just works - so perhaps as you're going through the course introduce some mistakes (like the one I mention above) and then know how to get yourself out of it.
Its bizarre how many clicks it takes to back out of some of these things. Practice for them.
@alexajo -
So there are a couple ways to fix things like this with iSCSI and NFS. One of the things that can be done is a storage domain can be put into maintenance mode and then "disconnected" from a DataCenter and connected to another DataCenter. However, in areas like the classroom environment, this can cause some problems as you are attaching it as the MASTER storage domain since it is the only domain we use in the course for the DataCenter. So that causes some special things to be on the storage domain as a data domain and it also causes the DataCenter to be Operational or Unresponsive being "DOWN" when that storage domain isn't working.
So in the instance you are making a new datacenter and creating the storage domain, there won't be anything on it (no VMs or anything else), you can remove the domain from RHV and wipe it. Not all versions support the wiping and removing of the storage domain, so when trying to use the iSCSI LUN again for another DataCenter it might state it is in use by another datacenter. What you can do in that case is use a tool like DD or something else to wipe the LUN.
Hope that helps.
@alexajo -
So there are a couple ways to fix things like this with iSCSI and NFS. One of the things that can be done is a storage domain can be put into maintenance mode and then "disconnected" from a DataCenter and connected to another DataCenter. However, in areas like the classroom environment, this can cause some problems as you are attaching it as the MASTER storage domain since it is the only domain we use in the course for the DataCenter. So that causes some special things to be on the storage domain as a data domain and it also causes the DataCenter to be Operational or Unresponsive being "DOWN" when that storage domain isn't working.
So in the instance you are making a new datacenter and creating the storage domain, there won't be anything on it (no VMs or anything else), you can remove the domain from RHV and wipe it. Not all versions support the wiping and removing of the storage domain, so when trying to use the iSCSI LUN again for another DataCenter it might state it is in use by another datacenter. What you can do in that case is use a tool like DD or something else to wipe the LUN.
Hope that helps.
Hello @alexajo ,
I agree with you and I believe it applies to any other course here. But speaking of RH318, I had an issue while uploading a disk via lab start command and for some reason the transaction lost the ticket. The disk got stuck with the "Finalizing" status. I tried different solutions, such as restarting "ovirt-imageio-proxy.service" on rhvm and ovirt-imageio-daemon.service on the host. I even tried to restart the RHVM environment and the Host too, but it didn't work.
I noticed I was able to upload the disk manually, but the other transaction was still there. So I read the RHVM log file (/var/log/ovirt-engine/engine.log) and that was the line complaining about the transaction:
2024-01-29 17:20:09,550+07 WARN [org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-13) [31c181633-a096-4c9c-b028-e8144ec9319a] Failed to stop image transfer session. Ticket does not exist for image '778982e6-d432-4398-af4f-5846a5a07ce'
To fix it, I had to delete this transaction directly from the database. I know it is very risky, but it worked.
So I accessed PostgreSQL:
su - postgres -c 'scl enable rh-postgresql10 -- psql'
Connected to the engine database:
postgres=# \connect engine
Checked the image_transfers table:
postgres=# select * from image_transfers;
And I was able to see the same ID transaction I was reading from the log file. Then I just delete the specific row:
postgres=# delete from image_transfers where disk_id = '778982e6-d432-4398-af4f-5846a5a07ce';
After this deletion the status changed to "OK"
I must say I like the way these RH exams are constructed. I hate exams where they ask you about switches of some command.
On this exam there was one question that made me smile. While it was not tricky it was .. interesting, no to spoil anything. I rollbacked 4-5 times before I made it (also due to typos). I tend to do typos (made many in my LAB sessions). I was surprised to lose points on datastore setup. I was actually expecting 100% on all but one topic.
Red Hat
Learning Community
A collaborative learning environment, enabling open source skill development.