alexajo
Flight Engineer
Flight Engineer
  • 681 Views

In this course its important to know how to back yourself out of situations

Jump to solution

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.

Labels (3)
1 Solution

Accepted Solutions
Travis
Moderator
Moderator
  • 658 Views

@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.

Travis Michette, RHCA XIII
https://rhtapps.redhat.com/verify?certId=111-134-086
SENIOR TECHNICAL INSTRUCTOR / CERTIFIED INSTRUCTOR AND EXAMINER
Red Hat Certification + Training

View solution in original post

3 Replies
Travis
Moderator
Moderator
  • 659 Views

@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.

Travis Michette, RHCA XIII
https://rhtapps.redhat.com/verify?certId=111-134-086
SENIOR TECHNICAL INSTRUCTOR / CERTIFIED INSTRUCTOR AND EXAMINER
Red Hat Certification + Training
Emanuel_Haine
Flight Engineer
Flight Engineer
  • 466 Views

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"

martindxc
Flight Engineer
Flight Engineer
  • 366 Views

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.

Join the discussion
You must log in to join this conversation.