Michel van Horssen píše v Pá 09. 03. 2012 v 10:30 +0100:
Hi,
Not sure if it's an engine or node problem but seeing that the eningine is functioning fine I'm putting my bets on the node.
I have a test install of ovirt on 3 servers.
FC 16 Engine/VDSM
FC 16 VDSM
Node version 2.2.3-1.1
I have 2 networks I need access to on all servers.
A. Default network for access to the servers
B. Data network for sharing iSCSI from an OpenFiler server.
I have an ISO nfs share on the engine server (1) and share an iSCSI disk on network B.
I needed to do a "hand job" on the node so it would get my 2nd network correctly because I couldn't do it from the TUI (is a known) and not from the engine interface.
Now for the problem:
I can create virtuel guests on all three servers. Running just fine. I can migrate away from all 3 servers while the guests are running. The thing is I can only migrate towards the VDSM servers (1 and 2) not to the Node (3).
The guest created on the node gets migrated away just fine but getting back on the node I get a:
"Migration failed due to Error: Fatal error during migration (VM: guestname, Source Host: VDSM-Host)"
Wich logs are needed to take a look at? Because I tried looking at the "/var/log/vdsm/vdsm.log" but that was to mixed up for me to find anything that pointed me in the right direction.
vdsm logs are most helpful. For starters, look up the VM names in the log and note its UUID. Then grep the logs for that UUID and you should see what happened to the VM.
qemu logs may also be of help, you can find them at /var/log/libvirt/qemu/<VM Name>
David
Any help is appreciated.
Thnx Michel _______________________________________________ node-devel mailing list node-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/node-devel
Thnx David,
Wil give it a go on Monday and tell what I find.
Michel
Not sure, but this sounds like a DNS issue. Does you reverse lookup of the host match the hostname?
----- Original Message -----
Michel van Horssen píše v Pá 09. 03. 2012 v 10:30 +0100:
Hi,
Not sure if it's an engine or node problem but seeing that the eningine is functioning fine I'm putting my bets on the node.
I have a test install of ovirt on 3 servers.
FC 16 Engine/VDSM
FC 16 VDSM
Node version 2.2.3-1.1
I have 2 networks I need access to on all servers.
A. Default network for access to the servers
B. Data network for sharing iSCSI from an OpenFiler server.
I have an ISO nfs share on the engine server (1) and share an iSCSI disk on network B.
I needed to do a "hand job" on the node so it would get my 2nd network correctly because I couldn't do it from the TUI (is a known) and not from the engine interface.
Now for the problem:
I can create virtuel guests on all three servers. Running just fine. I can migrate away from all 3 servers while the guests are running. The thing is I can only migrate towards the VDSM servers (1 and 2) not to the Node (3).
The guest created on the node gets migrated away just fine but getting back on the node I get a:
"Migration failed due to Error: Fatal error during migration (VM: guestname, Source Host: VDSM-Host)"
Wich logs are needed to take a look at? Because I tried looking at the "/var/log/vdsm/vdsm.log" but that was to mixed up for me to find anything that pointed me in the right direction.
vdsm logs are most helpful. For starters, look up the VM names in the log and note its UUID. Then grep the logs for that UUID and you should see what happened to the VM.
qemu logs may also be of help, you can find them at /var/log/libvirt/qemu/<VM Name>
David
Any help is appreciated.
Thnx Michel _______________________________________________ node-devel mailing list node-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/node-devel
--
David Jaša, RHCE
SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Hi,
Not sure, but this sounds like a DNS issue. Does you reverse lookup of the host match the hostname?
Personally I think it's a time issue. The node was one hour behind. Would be nice to have something in the TUI for setting the timezone.
Friday I've all the clocks on the same time and migrated some stuff to the node but it didn't work and I ran out of time. So I've shutdown all servers. This morning I started them up again and all is well except for 1 vm. It's in a "image locked" status and I can't get rid of it.
In the storage there is no longer a disk for that vm.
Is there a conf I can edit by hand so the engine forgets about this stray vm?
I want to solve this before I start a new test to see if the time issue resolved my problem.
Michel
----- Original Message -----
Hi,
Not sure, but this sounds like a DNS issue. Does you reverse lookup of the host match the hostname?
Personally I think it's a time issue. The node was one hour behind. Would be nice to have something in the TUI for setting the timezone.
Ah, you're barging into an open door here. Please configure NTP for all of your hosts.
Friday I've all the clocks on the same time and migrated some stuff to the node but it didn't work and I ran out of time. So I've shutdown all servers. This morning I started them up again and all is well except for 1 vm. It's in a "image locked" status and I can't get rid of it.
In the storage there is no longer a disk for that vm.
Is there a conf I can edit by hand so the engine forgets about this stray vm?
I want to solve this before I start a new test to see if the time issue resolved my problem.
Michel _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Hi,
Ah, you're barging into an open door here. Please configure NTP for all of your hosts.
Yeah, well, easier said then done, node wise :)
I've got NTP running and able. NTP is configured in the TUI, now I need to set the time zone, which is the reason the node is an hour backwards, and make it persistent thru reboots.
Michel
Hi,
Had some time to test some stuff again with my node not accepting a migration.
Okay the time issue is gone for now, I set the time the same manually on all servers. So I was sure that wouldn't be an issue.
Did a migration just now but still no luck.
Checked the logs and found the following:
On the host (FC16 and VDSM) that the VM is migrating away from I get the following error message in de /var/log/vdsm/vdsm.log
--- Thread-57::ERROR::2012-03-21 15:20:49,262::vm::170::vm.Vm::(_recover) vmId=`2b87786b-8a43-430e-877d-6f2647f6c593`::operation failed: Failed to connect to remote libvirt URI qemu+tls://192.168.10.78/system Thread-57::ERROR::2012-03-21 15:20:49,526::vm::234::vm.Vm::(run) vmId=`2b87786b-8a43-430e-877d-6f2647f6c593`::Traceback (most recent call last): File "/usr/share/vdsm/vm.py", line 217, in run self._startUnderlyingMigration() File "/usr/share/vdsm/libvirtvm.py", line 443, in _startUnderlyingMigration None, maxBandwidth) File "/usr/share/vdsm/libvirtvm.py", line 483, in f ret = attr(*args, **kwargs) File "/usr/share/vdsm/libvirtconnection.py", line 79, in wrapper ret = f(*args, **kwargs) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 971, in migrateToURI2 if ret == -1: raise libvirtError ('virDomainMigrateToURI2() failed', dom=self) libvirtError: operation failed: Failed to connect to remote libvirt URI qemu+tls://192.168.10.78/system ---
On the Node that the VM is migrating towards I get no error message in /var/log/vdsm/vdsm.log
Michel
vdsm-devel@lists.fedorahosted.org