[ovirt-users] 3.6.5.3: UI Uncaught Exception: New VM from Template
Hello list, I hope you can help with a UI exception from New VM from Template. 1. User (PowerUser) is able to create New VMs manually 2. New VM from template gives a UI exception: __gwt$exception: : Cannot read property 'f' of undefined 2016-05-08 11:04:50,875 ERROR [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService] (default task-28) [] Permutation name: 56114F8548175924C03C3BC67436871E 2016-05-08 11:04:50,875 ERROR [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService] (default task-28) [] Uncaught exception: : com.google.gwt.core.client.JavaScriptException: (TypeError) __gwt$exception: : f is undefined at org.ovirt.engine.ui.uicommonweb.models.storage.DisksAllocationModel.$updateImageToDestinationDomainMap(DisksAllocationModel.java:288) at org.ovirt.engine.ui.uicommonweb.models.storage.DisksAllocationModel.$getImageToDestinationDomainMap(DisksAllocationModel.java:130) at org.ovirt.engine.ui.uicommonweb.models.templates.VmBaseListModel.$saveNewVm(VmBaseListModel.java:354) at org.ovirt.engine.ui.uicommonweb.models.templates.VmBaseListModel.$onSaveVM(VmBaseListModel.java:331) at org.ovirt.engine.ui.uicommonweb.models.templates.VmBaseListModel$6.onSuccess(VmBaseListModel.java:309) at org.ovirt.engine.ui.frontend.Frontend$2.$onSuccess(Frontend.java:244) [frontend.jar:] -- Richard Chan ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] Problems exporting VM's
Hi everyone. I've been having trouble when exporting VM's. I get error when moving image. I've created a whole new storage domain exclusive for this issue, and same thing happens. It's not always the same VM that fails, but once it fails on a certain storage domain, I cannot export it anymore. Please tell me which logs are relevant so i can post them and any other relevant iformation I can provide, and maybe someone can help me get through this problem. Ovirt version is 3.5.4.2-1.el6. Hosted engines is CentOS 6. Hosts are CentOS 7. VM's are all CentOS 7, except for two that are CentOS 6 and Windows 7. Please excuse my bad english! Thanks in advance! -- Luciano Natale ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] configuring bonding on host
> Le 7 mai 2016 à 18:18, Juan Hernández a écrit : > > On 05/06/2016 05:20 PM, Fabrice Bacchella wrote: >> I'm following the example given >> in http://www.ovirt.org/develop/api/pythonapi/ for bonding interfaces. >> >> What am I missing ? >> > > The example that you mention describes the old and deprecated > /hosts/{host:id}/nics/setupnetworks action, but you are sending the > request to /hosts/{host:id}/setupnetworks, which just ignores the > "host_nics" elements that you are sending. There is an example of how to > use the newer action here: > > > https://jhernand.fedorapeople.org/ovirt-api-explorer/#/services/host/methods/setup-networks Ok.I got it. The samples says: host.nics.setupnetworks(...) And my code says: host.setupnetworks(...) But why does it silently ignore it ? Shouldn't it throw me an error ? I think I will soon have more questions about what is a modified or removed object when creating bond, but I will need to play a little more with it. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] configuring bonding on host
On 05/06/2016 05:20 PM, Fabrice Bacchella wrote: > I'm following the example given > in http://www.ovirt.org/develop/api/pythonapi/ for bonding interfaces. > > I'm checking that the network is a plain configuration, > exporting /api/hosts//nics return : > > href="/api/hosts/db240f83-9266-4892-a6d2-8ac406cadfb1/nics/958c40cd-9ddb-4548-8bd8-79f454021c35" > id="958c40cd-9ddb-4548-8bd8-79f454021c35"> > > href="/api/hosts/db240f83-9266-4892-a6d2-8ac406cadfb1/nics/958c40cd-9ddb-4548-8bd8-79f454021c35/attach" > rel="attach"/> > href="/api/hosts/db240f83-9266-4892-a6d2-8ac406cadfb1/nics/958c40cd-9ddb-4548-8bd8-79f454021c35/detach" > rel="detach"/> > > eth1 > href="/api/hosts/db240f83-9266-4892-a6d2-8ac406cadfb1/nics/958c40cd-9ddb-4548-8bd8-79f454021c35/statistics" > rel="statistics"/> > href="/api/hosts/db240f83-9266-4892-a6d2-8ac406cadfb1/nics/958c40cd-9ddb-4548-8bd8-79f454021c35/labels" > rel="labels"/> > href="/api/hosts/db240f83-9266-4892-a6d2-8ac406cadfb1/nics/958c40cd-9ddb-4548-8bd8-79f454021c35/networkattachments" > rel="networkattachments"/> > id="db240f83-9266-4892-a6d2-8ac406cadfb1"/> > > > none > > down > > 1500 > false > > > href="/api/hosts/db240f83-9266-4892-a6d2-8ac406cadfb1/nics/87a274e8-9633-45df-9205-1d188bd3ee4c" > id="87a274e8-9633-45df-9205-1d188bd3ee4c"> > > href="/api/hosts/db240f83-9266-4892-a6d2-8ac406cadfb1/nics/87a274e8-9633-45df-9205-1d188bd3ee4c/attach" > rel="attach"/> > href="/api/hosts/db240f83-9266-4892-a6d2-8ac406cadfb1/nics/87a274e8-9633-45df-9205-1d188bd3ee4c/detach" > rel="detach"/> > > eth0 > href="/api/hosts/db240f83-9266-4892-a6d2-8ac406cadfb1/nics/87a274e8-9633-45df-9205-1d188bd3ee4c/statistics" > rel="statistics"/> > href="/api/hosts/db240f83-9266-4892-a6d2-8ac406cadfb1/nics/87a274e8-9633-45df-9205-1d188bd3ee4c/labels" > rel="labels"/> > href="/api/hosts/db240f83-9266-4892-a6d2-8ac406cadfb1/nics/87a274e8-9633-45df-9205-1d188bd3ee4c/networkattachments" > rel="networkattachments"/> > id="db240f83-9266-4892-a6d2-8ac406cadfb1"/> > id="f429c46c-fed4-4c88-a000-36c021f5d633"/> > > address="10.83.17.24"/> > dhcp > 100 > > up > > 9000 > true > false > > > > I send my configuration and get : > >> POST /api/hosts/db240f83-9266-4892-a6d2-8ac406cadfb1/setupnetworks > HTTP/1.1 > ... >> my configuration > > < HTTP/1.1 200 OK > > < > < > < > < > < bond0 > < > < ovirtmgmt > < > < gateway="10.83.31.254"/> > < > < > < > < > < > < > < > < > < eth0 > < > < > < none > < 9000 > < > < > < eth1 > < > < > < none > < 9000 > < > < > < > < static > < 9000 > < true > < > < > < true > < false > < id="859bc27c-2060-4349-a0f5-dc1dd6333e6c"/> > < > < complete > < > < > > > So every thing is fine, I applied my configuration. > > But in the log, I get : > 2016-05-06 17:13:22,481 INFO > [org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand] > (default task-20) [30e54e04] Lock Acquired to object > 'EngineLock:{exclusiveLocks='[db240f83-9266-4892-a6d2-8ac406cadfb1= ACTION_TYPE_FAILED_SETUP_NETWORKS_IN_PROGRESS>]', > sharedLocks='null'}' > 2016-05-06 17:13:22,555 > INFO [org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand] > (default task-20) [30e54e04] Running command: HostSetupNetworksCommand > internal: false. Entities affected : ID: > db240f83-9266-4892-a6d2-8ac406cadfb1 Type: VDSAction group > CONFIGURE_HOST_NETWORK with role type ADMIN > 2016-05-06 17:13:22,555 > INFO [org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand] > (default task-20) [30e54e04] No changes were detected in setup networks > for host 'nb0101' (ID: 'db240f83-9266-4892-a6d2-8ac406cadfb1') > 2016-05-06 17:13:22,563 > INFO [org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand] > (default task-20) [30e54e04] Lock freed to object > 'EngineLock:{exclusiveLocks='[db240f83-9266-4892-a6d2-8ac406cadfb1= ACTION_TYPE_FAILED_SETUP_NETWORKS_IN_PROGRESS>]', > sharedLocks='null'}' > > And indeed my configuration is not changed. > > What am I missing ? > The example that you mention describes the old and deprecated /hosts/{host:id}/nics/setupnetworks action, but you are sending the request to /hosts/{host:id}/setupnetworks, which just ignor
Re: [ovirt-users] virt-in-virt problem: DHCP failing for a container in a oVirt VM
On Fri, May 6, 2016 at 11:07 PM, Will Dennis wrote: > That’s in iptables, right? I have iptables disabled on my oVirt nodes... > No, it's a L2 filter libvirt sets up, I believe using ebtables. Y. > > > *From:* Yaniv Kaul [mailto:yk...@redhat.com] > *Sent:* Friday, May 06, 2016 3:50 PM > *To:* Will Dennis > *Subject:* Re: [ovirt-users] virt-in-virt problem: DHCP failing for a > container in a oVirt VM > > > > Long shot - you need to disable the EnableMACAntiSpoofingFilterRules . > > Y. > > > > On Fri, May 6, 2016 at 8:27 PM, Will Dennis wrote: > > Hi all, > > > > Have an interesting problem – I am running a VM in oVirt that is running > Proxmox VE 4.1 OS, which I have spun up a container on. The container is > set for DHCP, and I have verified that it is sending Discover packets as > normal, and that these packets are making it out of the Proxmox VM to the > oVirt bridge (which is attached to a VLAN sub-interface of a bond > interface.) However, these packets do NOT make it past the oVirt bridge. > The interesting thing is that the Proxmox VM (as well as any other VM I > spin up on oVirt) works fine with DHCP. (I also have other oVirt VMs > instantiated which are using LXD to spin up containers, and I have the same > problem with those as well.) I checked a bunch of stuff, and the only clue > I could find is that it seems that the oVirt bridge is not learning the MAC > for the container on the VM, even though it does learn the VM’s MAC, but I > can capture DHCP traffic coming from the container off the ‘vnet0’ > interface which is joined to that bridge... > > > > Info: > > > > = off Proxmox VM = > > > > Container's MAC address: 32:62:65:61:65:33 > > > > root@proxmox-02:~# ip link sh > > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode > DEFAULT group default > > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > > 2: eth0: mtu 1500 qdisc pfifo_fast > master vmbr0 state UP mode DEFAULT group default qlen 1000 > > link/ether 00:1a:4a:16:01:57 brd ff:ff:ff:ff:ff:ff > > 3: vmbr0: mtu 1500 qdisc noqueue state > UP mode DEFAULT group default > > link/ether 00:1a:4a:16:01:57 brd ff:ff:ff:ff:ff:ff > > 7: veth100i0@if6: mtu 1500 qdisc > pfifo_fast master vmbr0 state UP mode DEFAULT group default qlen 1000 > > link/ether fe:50:4f:3c:bd:b8 brd ff:ff:ff:ff:ff:ff link-netnsid 0 > <<< veth connection to container > > > > root@proxmox-02:~# brctl showmacs vmbr0 > > port no mac addris local? ageing timer > > 1 00:12:3f:24:a4:54 no 112.88 > > 1 00:1a:4a:16:01:56 no 0.02 > > 1 00:1a:4a:16:01:57 yes0.00 > > 1 00:1a:4a:16:01:57 yes0.00 > > 1 00:24:50:dd:a2:05 no 1.37 > > 1 18:03:73:e3:be:5a no21.04 > > 1 18:03:73:e3:ca:24 no 4.23 > > 1 18:03:73:e3:cb:5b no48.41 > > 1 18:03:73:e3:cc:e5 no91.93 > > 1 18:03:73:e3:cd:b8 no 151.04 > > 1 18:03:73:e3:ce:43 no 0.80 > > 1 18:03:73:e3:d0:a4 no 290.74 > > 1 18:03:73:e3:d4:26 no34.06 > > 1 18:03:73:e3:d5:3d no 6.36 > > 1 18:03:73:e4:23:08 no88.76 > > 1 18:03:73:e4:25:92 no 111.86 > > 1 18:03:73:e4:26:2f no 9.54 > > 1 18:03:73:e4:2b:4c no 114.86 > > 1 18:03:73:e4:31:15 no 263.91 > > 1 18:03:73:e4:6c:19 no 6.36 > > 1 18:03:73:e4:7e:0a no 103.06 > > 1 18:03:73:e8:16:e0 no23.21 > > 2 32:62:65:61:65:33 no 5.08 <<< container’s > MAC learned on Proxmox bridge > > 1 34:17:eb:9b:e0:29 no 265.22 > > 1 34:17:eb:9b:f8:ea no 114.86 > > 1 44:d3:ca:7e:3c:ff no 0.00 > > 1 78:2b:cb:3b:ca:b9 no 284.70 > > 1 78:2b:cb:92:cb:cb no 279.70 > > 1 78:2b:cb:93:08:a8 no 287.05 > > 1 b8:ca:3a:7a:70:63 no 4.83 > > 1 f8:bc:12:69:bb:a3 no 121.82 > > 2 fe:50:4f:3c:bd:b8 yes0.00 > > 2 fe:50:4f:3c:bd:b8 yes0.00 > > > > = off oVirt node that has Proxmox VM > > > > (relevant lines from ‘ip link show’) > > 2: bond0: mtu 1500 qdisc noqueue > state UP mode DEFAULT > > 3: enp4s0f0: mtu 1500 qdisc > pfifo_fast master bond0 state UP mode DEFAULT qlen 1000 > > 4: enp4s0f1: mtu 1500 qdisc > pfifo_fast master bond0 state UP mode DEFAULT qlen 1000 > > 8: bond0.169@bond0: mtu 1500 qdisc > noqueue master 169-net state UP mode DEFAULT > > 10: bond0.180@bond0: mtu 1500 qdisc > no