Re: [Users] Network issues - Bonding
It's FC 19 with all of the latest updates. On 01/06/2014 05:56 AM, Sven Kieske wrote: > Hi, > > just out of curiosity (I'm also looking > at implementing bonding on our ComputeNodes): > > Which OS version are you running ? > > ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] Network issues - Bonding
Hello All, A little bit ago I wrote an email about network issues I was having. I found the problem... On the VM host, I had a bond set up between two network interfaces. The bond mode was set to mode 1 (active/passive). However when I look at the bond on the box, I get this: [root@node02 bonding]# cat bond4 Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) Bonding Mode: load balancing (round-robin) MII Status: up MII Polling Interval (ms): 0 Up Delay (ms): 0 Down Delay (ms): 0 Slave Interface: em2 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: d4:ae:52:6d:c8:cc Slave queue ID: 0 Slave Interface: em3 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: d4:ae:52:6d:c8:ce Slave queue ID: 0 Somehow, the OS is not setting the bonding mode right. I verified that it was set to mode 1 in /etc/sysconfig/network-scripts/ifcfe-bond4 When I take the bond away, the host network works perfectly on both of the formerly bonded interfaces. So again, if anyone has any ideas, I'm open to suggestions. Thanks, Dan ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] Another issue - VM Networking
I've run into another issue with Ovirt 3.3.2. We have a 2 node VM cluster with Fibre Channel storage. After upgrade everything to FC 19 and installing Ovirt 3.3 from scratch one of the nodes has network issues. The issue is that when we start a VM on the node, the VM cannot access the network. No ping, no ssh, nothing. However, if I try to ping the VM, I can see the ICMP traffic on the ethernet VLAN interface and the bridge interface. I cannot see any traffic on the VM tap interface. If we migrate the VM from the faulty node to the other node that works, and then back, the network will start to work. However, if the VM is shut down the network will fail again when it's booted on the faulty node. Does anyone have any ideas about this particular problem? Thanks, Dan ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] Help - Cannot run VM. Invalid time zone for given OS type.
Hi, Has anyone run across this error: Cannot run VM. Invalid time zone for given OS type. The OS type for these VMs is set to Linux Other. They were all exported from an Ovirt 3.2 cluster and are being reimported into an Ovirt 3.3 cluster. None of these VMs will boot. We also can't delete them because delete protection is enabled and we can't edit the VM to turn off delete protection. Does anyone know what this error means exactly and how to fix it? Thanks, Dan ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] vdsmd seg fault
Unfortunatly, I was not correct. Not fixed. :( VDSM died randomly yesterday. This was the message from systemctl: vdsmd.service - Virtual Desktop Server Manager Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled) Active: failed (Result: exit-code) since Fri 2013-10-25 12:06:29 EDT; 7s ago Process: 20937 ExecStop=/lib/systemd/systemd-vdsmd stop (code=exited, status=0/SUCCESS) Process: 21498 ExecStart=/lib/systemd/systemd-vdsmd start (code=exited, status=139) Main PID: 5205 (code=killed, signal=TERM) CGroup: name=systemd:/system/vdsmd.service Oct 25 12:06:29 rs0-ovirt0 python[21572]: DIGEST-MD5 ask_user_info() Oct 25 12:06:29 rs0-ovirt0 python[21572]: DIGEST-MD5 client step 2 Oct 25 12:06:29 rs0-ovirt0 python[21572]: DIGEST-MD5 ask_user_info() Oct 25 12:06:29 rs0-ovirt0 python[21572]: DIGEST-MD5 make_client_response() Oct 25 12:06:29 rs0-ovirt0 python[21572]: DIGEST-MD5 client step 3 Oct 25 12:06:29 rs0-ovirt0 systemd-vdsmd[21498]: libvirt: Network Filter Driver error : Requested operation is not valid: nwfilter is in use Oct 25 12:06:29 rs0-ovirt0 systemd-vdsmd[21498]: /lib/systemd/systemd-vdsmd: line 186: 21572 Segmentation fault "$VDSM_TOOL" nwfilter Oct 25 12:06:29 rs0-ovirt0 systemd[1]: vdsmd.service: control process exited, code=exited status=139 Oct 25 12:06:29 rs0-ovirt0 systemd[1]: Failed to start Virtual Desktop Server Manager. Oct 25 12:06:29 rs0-ovirt0 systemd[1]: Unit vdsmd.service entered failed state. On 10/22/2013 8:41 PM, Dan Ferris wrote: So, just an update... I upgraded to Ovirt 3.3.0.1 today and I have the latest libvirt. I *THINK* the issue may be gone, but I will have to do a little more testing. Dan On 10/18/2013 11:15 AM, Dan Ferris wrote: That did work. vdsmd decided it would start again. Dan On 10/17/2013 3:15 PM, Jason Brooks wrote: - Original Message - From: "Dan Ferris" To: "" Sent: Tuesday, October 15, 2013 9:24:44 AM Subject: [Users] vdsmd seg fault I updated to the latest Fedora 19 on two test servers, and now vdsmd will not start. Systedctl says this: dsmd.service - Virtual Desktop Server Manager Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled) Active: failed (Result: exit-code) since Mon 2013-10-14 12:31:30 EDT; 23h ago Process: 1788 ExecStart=/lib/systemd/systemd-vdsmd start (code=exited, status=139) Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 ask_user_info() Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 client step 2 Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 ask_user_info() Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 make_client_response() Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 client step 3 Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd-vdsmd[1788]: /lib/systemd/systemd-vdsmd: line 185: 1862 Segmentation fault "$VDSM_TOOL" nwfilter Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd-vdsmd[1788]: vdsm: Failed to define network filters on libvirt[FAILED] Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd[1]: vdsmd.service: control process exited, code=exited status=139 Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd[1]: Failed to start Virtual Desktop Server Manager. Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd[1]: Unit vdsmd.service entered failed state. Has anyone else experienced this? I just hit this on one of my test installs. I did yum downgrade libvirt* and then vdsmd would start Jason Dan ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] vdsmd seg fault
So, just an update... I upgraded to Ovirt 3.3.0.1 today and I have the latest libvirt. I *THINK* the issue may be gone, but I will have to do a little more testing. Dan On 10/18/2013 11:15 AM, Dan Ferris wrote: That did work. vdsmd decided it would start again. Dan On 10/17/2013 3:15 PM, Jason Brooks wrote: - Original Message - From: "Dan Ferris" To: "" Sent: Tuesday, October 15, 2013 9:24:44 AM Subject: [Users] vdsmd seg fault I updated to the latest Fedora 19 on two test servers, and now vdsmd will not start. Systedctl says this: dsmd.service - Virtual Desktop Server Manager Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled) Active: failed (Result: exit-code) since Mon 2013-10-14 12:31:30 EDT; 23h ago Process: 1788 ExecStart=/lib/systemd/systemd-vdsmd start (code=exited, status=139) Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 ask_user_info() Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 client step 2 Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 ask_user_info() Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 make_client_response() Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 client step 3 Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd-vdsmd[1788]: /lib/systemd/systemd-vdsmd: line 185: 1862 Segmentation fault "$VDSM_TOOL" nwfilter Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd-vdsmd[1788]: vdsm: Failed to define network filters on libvirt[FAILED] Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd[1]: vdsmd.service: control process exited, code=exited status=139 Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd[1]: Failed to start Virtual Desktop Server Manager. Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd[1]: Unit vdsmd.service entered failed state. Has anyone else experienced this? I just hit this on one of my test installs. I did yum downgrade libvirt* and then vdsmd would start Jason Dan ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] vdsmd seg fault
That did work. vdsmd decided it would start again. Dan On 10/17/2013 3:15 PM, Jason Brooks wrote: - Original Message - From: "Dan Ferris" To: "" Sent: Tuesday, October 15, 2013 9:24:44 AM Subject: [Users] vdsmd seg fault I updated to the latest Fedora 19 on two test servers, and now vdsmd will not start. Systedctl says this: dsmd.service - Virtual Desktop Server Manager Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled) Active: failed (Result: exit-code) since Mon 2013-10-14 12:31:30 EDT; 23h ago Process: 1788 ExecStart=/lib/systemd/systemd-vdsmd start (code=exited, status=139) Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 ask_user_info() Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 client step 2 Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 ask_user_info() Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 make_client_response() Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 client step 3 Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd-vdsmd[1788]: /lib/systemd/systemd-vdsmd: line 185: 1862 Segmentation fault "$VDSM_TOOL" nwfilter Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd-vdsmd[1788]: vdsm: Failed to define network filters on libvirt[FAILED] Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd[1]: vdsmd.service: control process exited, code=exited status=139 Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd[1]: Failed to start Virtual Desktop Server Manager. Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd[1]: Unit vdsmd.service entered failed state. Has anyone else experienced this? I just hit this on one of my test installs. I did yum downgrade libvirt* and then vdsmd would start Jason Dan ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] vdsmd seg fault
On 10/16/2013 7:27 AM, Douglas Schilling Landgraf wrote: On 10/16/2013 02:27 AM, Dan Kenigsberg wrote: On Tue, Oct 15, 2013 at 10:24:44AM -0600, Dan Ferris wrote: I updated to the latest Fedora 19 on two test servers, and now vdsmd will not start. Systedctl says this: dsmd.service - Virtual Desktop Server Manager Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled) Active: failed (Result: exit-code) since Mon 2013-10-14 12:31:30 EDT; 23h ago Process: 1788 ExecStart=/lib/systemd/systemd-vdsmd start (code=exited, status=139) Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 ask_user_info() Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 client step 2 Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 ask_user_info() Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 make_client_response() Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 client step 3 Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd-vdsmd[1788]: /lib/systemd/systemd-vdsmd: line 185: 1862 Segmentation fault "$VDSM_TOOL" nwfilter Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd-vdsmd[1788]: vdsm: Failed to define network filters on libvirt[FAILED] Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd[1]: vdsmd.service: control process exited, code=exited status=139 Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd[1]: Failed to start Virtual Desktop Server Manager. Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd[1]: Unit vdsmd.service entered failed state. Has anyone else experienced this? I haven't. Does the segfault introduce when you run gdb vdsm-tool nwfilter as root? Could you send the output of `bt full` if it does? ___ Also, is libvirt daemon running? Yep, it sure is. I just checked. Dan ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] vdsmd seg fault
On 10/16/2013 8:55 AM, Dan Kenigsberg wrote: On Wed, Oct 16, 2013 at 08:33:10AM -0600, Dan Ferris wrote: On 10/16/2013 12:27 AM, Dan Kenigsberg wrote: On Tue, Oct 15, 2013 at 10:24:44AM -0600, Dan Ferris wrote: I updated to the latest Fedora 19 on two test servers, and now vdsmd will not start. Systedctl says this: dsmd.service - Virtual Desktop Server Manager Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled) Active: failed (Result: exit-code) since Mon 2013-10-14 12:31:30 EDT; 23h ago Process: 1788 ExecStart=/lib/systemd/systemd-vdsmd start (code=exited, status=139) Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 ask_user_info() Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 client step 2 Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 ask_user_info() Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 make_client_response() Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 client step 3 Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd-vdsmd[1788]: /lib/systemd/systemd-vdsmd: line 185: 1862 Segmentation fault "$VDSM_TOOL" nwfilter Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd-vdsmd[1788]: vdsm: Failed to define network filters on libvirt[FAILED] Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd[1]: vdsmd.service: control process exited, code=exited status=139 Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd[1]: Failed to start Virtual Desktop Server Manager. Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd[1]: Unit vdsmd.service entered failed state. Has anyone else experienced this? I haven't. Does the segfault introduce when you run gdb vdsm-tool nwfilter as root? Could you send the output of `bt full` if it does? gdb is complaining that vdsm-tool is a python script and not in elf format. doh me. `gdb python`, followed by `run /usr/bin/vdsm-tool nwfilter` is what should be done. However, running vdsm-tool nwfilter runs and has a return code of 0. But when it's called via systemd, the segfault still reproduces? Dan. Yeah, that's correct. It segfaults when it runs from systemd. I just ran it from gdb: GNU gdb (GDB) Fedora 7.6.1-41.fc19 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/python2.7...Reading symbols from /usr/bin/python2.7...(no debugging symbols found)...done. (no debugging symbols found)...done. Missing separate debuginfos, use: debuginfo-install python-2.7.5-8.fc19.x86_64 (gdb) run /usr/bin/vdsm-tool nwfilter Starting program: /usr/bin/python /usr/bin/vdsm-tool nwfilter [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7fffe4bb8700 (LWP 8808)] [Thread 0x77fec740 (LWP 8804) exited] [Inferior 1 (process 8804) exited normally] (gdb) bt full No stack. Looks like it's happy. Is there any other info you want about my system? I'm even willing to let somebody log in and poke around. Dan ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] vdsmd seg fault
On 10/16/2013 12:27 AM, Dan Kenigsberg wrote: On Tue, Oct 15, 2013 at 10:24:44AM -0600, Dan Ferris wrote: I updated to the latest Fedora 19 on two test servers, and now vdsmd will not start. Systedctl says this: dsmd.service - Virtual Desktop Server Manager Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled) Active: failed (Result: exit-code) since Mon 2013-10-14 12:31:30 EDT; 23h ago Process: 1788 ExecStart=/lib/systemd/systemd-vdsmd start (code=exited, status=139) Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 ask_user_info() Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 client step 2 Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 ask_user_info() Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 make_client_response() Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 client step 3 Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd-vdsmd[1788]: /lib/systemd/systemd-vdsmd: line 185: 1862 Segmentation fault "$VDSM_TOOL" nwfilter Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd-vdsmd[1788]: vdsm: Failed to define network filters on libvirt[FAILED] Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd[1]: vdsmd.service: control process exited, code=exited status=139 Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd[1]: Failed to start Virtual Desktop Server Manager. Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd[1]: Unit vdsmd.service entered failed state. Has anyone else experienced this? I haven't. Does the segfault introduce when you run gdb vdsm-tool nwfilter as root? Could you send the output of `bt full` if it does? gdb is complaining that vdsm-tool is a python script and not in elf format. However, running vdsm-tool nwfilter runs and has a return code of 0. Dan ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] vdsmd seg fault
I updated to the latest Fedora 19 on two test servers, and now vdsmd will not start. Systedctl says this: dsmd.service - Virtual Desktop Server Manager Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled) Active: failed (Result: exit-code) since Mon 2013-10-14 12:31:30 EDT; 23h ago Process: 1788 ExecStart=/lib/systemd/systemd-vdsmd start (code=exited, status=139) Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 ask_user_info() Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 client step 2 Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 ask_user_info() Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 make_client_response() Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 client step 3 Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd-vdsmd[1788]: /lib/systemd/systemd-vdsmd: line 185: 1862 Segmentation fault "$VDSM_TOOL" nwfilter Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd-vdsmd[1788]: vdsm: Failed to define network filters on libvirt[FAILED] Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd[1]: vdsmd.service: control process exited, code=exited status=139 Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd[1]: Failed to start Virtual Desktop Server Manager. Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd[1]: Unit vdsmd.service entered failed state. Has anyone else experienced this? Dan ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Recommended Storage Hardware
A few decent Linux servers and LIO is what we use. LIO works pretty well. Dan On 10/8/2013 11:12 AM, Zachary Musselman wrote: Hello, My company is looking to deploy ovirt. We are looking for recommendations for storage hardware. What vendors or appliances are individuals using with iscsi protocol? Thanks ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Disk state - Illegal?
I was off today, so I just saw this. I will try it out tomorrow. Thanks! Dan On 9/25/2013 8:53 PM, Andrew Lau wrote: I noticed that too, I wasn't sure if it was a bug or just how I had setup my NFS share.. There were three steps I did to remove the disk images, I'm sure there's a 100% easier solution..: I found the easiest way (graphically) was go to your https://ovirtengine/api/disks and so a search for the illegal disk. Append the extra ID eg. https://ovirtengine/disks/disk-id send a DELETE using HTTP/CURL Again, this was a poor mans solution but it worked for me. On Thu, Sep 26, 2013 at 4:04 AM, Dan Ferris mailto:dfer...@prometheusresearch.com>>wrote: Hi, I have another hopefully simple question. One VM that I am trying to remove says that it's disk state is "illegal" and when I try to remove the disk it says that it failed to initiate the removing of the disk. Is there an easy way to get rid of these illegal disk images? Dan _ Users mailing list Users@ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/__mailman/listinfo/users <http://lists.ovirt.org/mailman/listinfo/users> ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] Disk state - Illegal?
Hi, I have another hopefully simple question. One VM that I am trying to remove says that it's disk state is "illegal" and when I try to remove the disk it says that it failed to initiate the removing of the disk. Is there an easy way to get rid of these illegal disk images? Dan ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Unable to attach to storage domain (Ovirt 3.2)
We actually got it working. Both of us were tired from working late, so
we didn't find that the missing storage domain was actually one of the
NFS exports for awhile. After removing our NFS ISO domain and NFS
export domain everything came up.
Dan
On 9/22/13 6:08 AM, Ayal Baron wrote:
If I understand correctly you have a storage domain which is built of multiple
(at least 2) LUNs.
One of these LUNs seems to be missing (Wy3Ymi-J7bJ-hVxg-sg3L-F5Gv-MQmz-Utwv7z
is an LVM PV UUID).
It looks like you are either not fully connected to the storage server (missing
a connection) or the LUN mapping in LIO has been changed or that the chap
password has changed or something.
LVM is able to report the LVs since the PV which contains the metadata is still
accessible (which is also why you see the VG and why LVM knows that the
Wy3Ymi... device is missing).
Can you compress and attach *all* of the vdsm.log* files?
- Original Message -
Hi Dan, it looks like one of the domains is missing:
6cf7e7e9-3ae5-4645-a29c-fb17ecb38a50
Is there any target missing? (disconnected or somehow faulty or
unreachable)
--
Federico
- Original Message -
From: "Dan Ferris"
To: users@ovirt.org
Sent: Friday, September 20, 2013 4:01:06 AM
Subject: [Users] Unable to attach to storage domain (Ovirt 3.2)
Hi,
This is my first post to the list. I am happy to say that we have been
using Ovirt for 6 months with a few bumps, but it's mostly been ok.
Until tonight that is...
I had to do a maintenance that required rebooting both of our Hypervisor
nodes. Both of them run Fedora Core 18 and have been happy for months.
After rebooting them tonight, they will not attach to the storage. If
it matters, the storage is a server running LIO with a Fibre Channel
target.
Vdsm log:
Thread-22::DEBUG::2013-09-19
21:57:09,392::misc::84::Storage.Misc.excCmd::() '/usr/bin/dd
iflag=direct if=/dev/b358e46b-635b-4c0e-8e73-0a494602e21d/metadata
bs=4096 count=1' (cwd None)
Thread-22::DEBUG::2013-09-19
21:57:09,400::misc::84::Storage.Misc.excCmd::() SUCCESS: =
'1+0 records in\n1+0 records out\n4096 bytes (4.1 kB) copied,
0.000547161 s, 7.5 MB/s\n'; = 0
Thread-23::DEBUG::2013-09-19
21:57:16,587::lvm::368::OperationMutex::(_reloadvgs) Operation 'lvm
reload operation' got the operation mutex
Thread-23::DEBUG::2013-09-19
21:57:16,587::misc::84::Storage.Misc.excCmd::() u'/usr/bin/sudo
-n /sbin/lvm vgs --config " devices { preferred_names =
[\\"^/dev/mapper/\\"] ignore_suspended_devices=1 write_cache_state=0
disable_after_error_count=3 filter = [
\\"a%360014055193f840cb3743f9befef7aa3%\\", \\"r%.*%\\" ] } global {
locking_type=1 prioritise_write_locks=1 wait_for_locks=1 } backup {
retain_min = 50 retain_days = 0 } " --noheadings --units b --nosuffix
--separator | -o
uuid,name,attr,size,free,extent_size,extent_count,free_count,tags,vg_mda_size,vg_mda_free
6cf7e7e9-3ae5-4645-a29c-fb17ecb38a50' (cwd None)
Thread-23::DEBUG::2013-09-19
21:57:16,643::misc::84::Storage.Misc.excCmd::() FAILED: =
' Volume group "6cf7e7e9-3ae5-4645-a29c-fb17ecb38a50" not found\n';
= 5
Thread-23::WARNING::2013-09-19
21:57:16,649::lvm::373::Storage.LVM::(_reloadvgs) lvm vgs failed: 5 []
[' Volume group "6cf7e7e9-3ae5-4645-a29c-fb17ecb38a50" not found']
Thread-23::DEBUG::2013-09-19
21:57:16,649::lvm::397::OperationMutex::(_reloadvgs) Operation 'lvm
reload operation' released the operation mutex
Thread-23::ERROR::2013-09-19
21:57:16,650::domainMonitor::208::Storage.DomainMonitorThread::(_monitorDomain)
Error while collecting domain 6cf7e7e9-3ae5-4645-a29c-fb17ecb38a50
monitoring information
Traceback (most recent call last):
File "/usr/share/vdsm/storage/domainMonitor.py", line 182, in
_monitorDomain
self.domain = sdCache.produce(self.sdUUID)
File "/usr/share/vdsm/storage/sdc.py", line 97, in produce
domain.getRealDomain()
File "/usr/share/vdsm/storage/sdc.py", line 52, in getRealDomain
return self._cache._realProduce(self._sdUUID)
File "/usr/share/vdsm/storage/sdc.py", line 121, in _realProduce
domain = self._findDomain(sdUUID)
File "/usr/share/vdsm/storage/sdc.py", line 152, in _findDomain
raise se.StorageDomainDoesNotExist(sdUUID)
StorageDomainDoesNotExist: Storage domain does not exist:
(u'6cf7e7e9-3ae5-4645-a29c-fb17ecb38a50',)
vgs output (Note that I don't know what the device
(Wy3Ymi-J7bJ-hVxg-sg3L-F5Gv-MQmz-Utwv7z is) :
[root@node01 vdsm]# vgs
Couldn't find device with uuid Wy3Ymi-J7bJ-hVxg-sg3L-F5Gv-MQmz-Utwv7z.
VG #PV #LV #SN Attr VSize VFree
b358e46b-635b-4c0e-8e73-0a494602e21d 1 39 0 wz--n- 8.19t 5.88t
build 2 2 0 wz-pn- 299.75g 16.00m
fedora
[Users] Unable to attach to storage domain (Ovirt 3.2)
Hi,
This is my first post to the list. I am happy to say that we have been
using Ovirt for 6 months with a few bumps, but it's mostly been ok.
Until tonight that is...
I had to do a maintenance that required rebooting both of our Hypervisor
nodes. Both of them run Fedora Core 18 and have been happy for months.
After rebooting them tonight, they will not attach to the storage. If
it matters, the storage is a server running LIO with a Fibre Channel target.
Vdsm log:
Thread-22::DEBUG::2013-09-19
21:57:09,392::misc::84::Storage.Misc.excCmd::() '/usr/bin/dd
iflag=direct if=/dev/b358e46b-635b-4c0e-8e73-0a494602e21d/metadata
bs=4096 count=1' (cwd None)
Thread-22::DEBUG::2013-09-19
21:57:09,400::misc::84::Storage.Misc.excCmd::() SUCCESS: =
'1+0 records in\n1+0 records out\n4096 bytes (4.1 kB) copied,
0.000547161 s, 7.5 MB/s\n'; = 0
Thread-23::DEBUG::2013-09-19
21:57:16,587::lvm::368::OperationMutex::(_reloadvgs) Operation 'lvm
reload operation' got the operation mutex
Thread-23::DEBUG::2013-09-19
21:57:16,587::misc::84::Storage.Misc.excCmd::() u'/usr/bin/sudo
-n /sbin/lvm vgs --config " devices { preferred_names =
[\\"^/dev/mapper/\\"] ignore_suspended_devices=1 write_cache_state=0
disable_after_error_count=3 filter = [
\\"a%360014055193f840cb3743f9befef7aa3%\\", \\"r%.*%\\" ] } global {
locking_type=1 prioritise_write_locks=1 wait_for_locks=1 } backup {
retain_min = 50 retain_days = 0 } " --noheadings --units b --nosuffix
--separator | -o
uuid,name,attr,size,free,extent_size,extent_count,free_count,tags,vg_mda_size,vg_mda_free
6cf7e7e9-3ae5-4645-a29c-fb17ecb38a50' (cwd None)
Thread-23::DEBUG::2013-09-19
21:57:16,643::misc::84::Storage.Misc.excCmd::() FAILED: =
' Volume group "6cf7e7e9-3ae5-4645-a29c-fb17ecb38a50" not found\n';
= 5
Thread-23::WARNING::2013-09-19
21:57:16,649::lvm::373::Storage.LVM::(_reloadvgs) lvm vgs failed: 5 []
[' Volume group "6cf7e7e9-3ae5-4645-a29c-fb17ecb38a50" not found']
Thread-23::DEBUG::2013-09-19
21:57:16,649::lvm::397::OperationMutex::(_reloadvgs) Operation 'lvm
reload operation' released the operation mutex
Thread-23::ERROR::2013-09-19
21:57:16,650::domainMonitor::208::Storage.DomainMonitorThread::(_monitorDomain)
Error while collecting domain 6cf7e7e9-3ae5-4645-a29c-fb17ecb38a50
monitoring information
Traceback (most recent call last):
File "/usr/share/vdsm/storage/domainMonitor.py", line 182, in
_monitorDomain
self.domain = sdCache.produce(self.sdUUID)
File "/usr/share/vdsm/storage/sdc.py", line 97, in produce
domain.getRealDomain()
File "/usr/share/vdsm/storage/sdc.py", line 52, in getRealDomain
return self._cache._realProduce(self._sdUUID)
File "/usr/share/vdsm/storage/sdc.py", line 121, in _realProduce
domain = self._findDomain(sdUUID)
File "/usr/share/vdsm/storage/sdc.py", line 152, in _findDomain
raise se.StorageDomainDoesNotExist(sdUUID)
StorageDomainDoesNotExist: Storage domain does not exist:
(u'6cf7e7e9-3ae5-4645-a29c-fb17ecb38a50',)
vgs output (Note that I don't know what the device
(Wy3Ymi-J7bJ-hVxg-sg3L-F5Gv-MQmz-Utwv7z is) :
[root@node01 vdsm]# vgs
Couldn't find device with uuid Wy3Ymi-J7bJ-hVxg-sg3L-F5Gv-MQmz-Utwv7z.
VG #PV #LV #SN Attr VSize VFree
b358e46b-635b-4c0e-8e73-0a494602e21d 1 39 0 wz--n- 8.19t 5.88t
build 2 2 0 wz-pn- 299.75g 16.00m
fedora 1 3 0 wz--n- 557.88g 0
lvs output:
[root@node01 vdsm]# lvs
Couldn't find device with uuid Wy3Ymi-J7bJ-hVxg-sg3L-F5Gv-MQmz-Utwv7z.
LV VG
Attr LSizePool Origin Data% Move Log Copy% Convert
0b8cca47-313f-48da-84f2-154810790d5a
b358e46b-635b-4c0e-8e73-0a494602e21d -wi-a 40.00g
0f6f7572-8797-4d84-831b-87dbc4e1aa48
b358e46b-635b-4c0e-8e73-0a494602e21d -wi-a 100.00g
19a1473f-c375-411f-9a02-c6054b9a28d2
b358e46b-635b-4c0e-8e73-0a494602e21d -wi-a 50.00g
221144dc-51dc-46ae-9399-c0b8e030f38a
b358e46b-635b-4c0e-8e73-0a494602e21d -wi-a 40.00g
2386932f-5f68-46e1-99a4-e96c944ac21b
b358e46b-635b-4c0e-8e73-0a494602e21d -wi-a 40.00g
3e027010-931b-43d6-9c9f-eeeabbdcd47a
b358e46b-635b-4c0e-8e73-0a494602e21d -wi-a2.00g
4257ccc2-94d5-4d71-b21a-c188acbf7ca1
b358e46b-635b-4c0e-8e73-0a494602e21d -wi-a 200.00g
4979b2a4-04aa-46a1-be0d-f10be0a1f587
b358e46b-635b-4c0e-8e73-0a494602e21d -wi-a 100.00g
4e1b8a1a-1704-422b-9d79-60f15e165cb7
b358e46b-635b-4c0e-8e73-0a494602e21d -wi-a 40.00g
70bce792-410f-479f-8e04-a2a4093d3dfb
b358e46b-635b-4c0e-8e73-0a494602e21d -wi-a 100.00g
791f6bda-c7eb-4d90-84c1-d7e33e73de62
b358e46b-635b-4c0e-8e73-0a494602e21d -wi-a 100.00g
818ad6bc-8da2-4099-b38a-8c5b52f69e32
b358e46b-635b-4c0e-8e73-0a494602e21d -wi-a 120.00g
861c9c44-fdeb-43cd-8e5c-32c00ce3cd3d
b358e46b-635b-4c0e-8e73-0a494602e21d -wi-a 100.00g
86b69521-14db-43d1-801f-9d21f
