[ovirt-users] API -- Do I need to use templates? Can I change network for the nic?

Thu Oct 2 21:05:45 UTC 2014

I'm actually having issues across the board...maybe its because I'm going
against the design ideals but I was told that in order to use the local
storage on the box and sacrifice VM migration capabilities, all machines
had to be in their own datacenter. Pain point number one.

Second pain point is adding additional networks aside from the initial
management network doesn't seem to be very intuitive. I'm a network
engineer for a living...and I can't figure it out.

Third pain point is ovirt management UI requires a restart semi frequently
due to crashing.

I added the network under the networks tab, but I noticed it doesn't ask
any interface questions (ok, it could technically attempt arp on all
interfaces like a citrix netscaler). I notice theres no ifconfig changes on
the host. I also notice that the other interface has a bridge named exactly
as the management name in the UI; ovirtmgmt, which is bridged to eth0. OK,
so I create a bridge called utility (my network name) and mapped it to a
vlan tagged interface I had setup on eth1.21. Everything looks identical to
how ovirt setup the initial network. The interface itself works, I can see
things on the network etc. Traffic passes.

Trying to run the VM results in errors because its failing network filters,
says it doesn't exist etc. All I want to do, is create a VM with some
memory, some disk, with a nic on a network, across individual machines. My
PXE provisioning will take over from there. Whats the best way to do this?
Sorry for all the questions -- your guys' response is great, and I really
appreciate the help thus far.

The exact message I get is:

Error while executing action:
utiltest:

   - Cannot run VM. There are no available running Hosts with all the
   networks used by the VM.
   - Cannot run VM. There is no host that satisfies current scheduling
   constraints. See below for details:
   - The host load3.pod1.########.com did not satisfy internal filter
   Network

Thanks,
Morgan

On Thu, Oct 2, 2014 at 1:30 AM, Morgan McLean <wrx230 at gmail.com> wrote:

> Hi,
>
> I think template configuration is definitely not an option for networks
> with a large amount of segments.
>
> I haven't played with VNIC profiles, but I will tomorrow. I didn't
> remember seeing any documentation on changing that with a PUT, but I'll
> look into it. Will report back shortly, thank you!
>
> Morgan
>
>
> On Thursday, October 2, 2014, Lior Vernia <lvernia at redhat.com> wrote:
>
>>
>>
>> On 02/10/14 10:22, Tomas Jelinek wrote:
>> >
>> >
>> > ----- Original Message -----
>> >> From: "Itamar Heim" <iheim at redhat.com>
>> >> To: "Lior Vernia" <lvernia at redhat.com>, "Morgan McLean" <
>> wrx230 at gmail.com>
>> >> Cc: users at ovirt.org
>> >> Sent: Wednesday, October 1, 2014 12:38:13 PM
>> >> Subject: Re: [ovirt-users] API -- Do I need to use templates? Can I
>> change network for the nic?
>> >>
>> >> On 10/01/2014 10:54 AM, Lior Vernia wrote:
>> >>> Hi Morgan,
>> >>>
>> >>> I'm not sure if you want all VMs to use the same network or not. If
>> you
>> >>> do, the best way would be to create a template with one interface, and
>> >>> the relevant network (profile) attached.
>> >>>
>> >>> If you want certain VMs to be connected to other networks, once you
>> >>> create the VM you can send a PUT request on /api/vms/{id}/nics/{id}/
>> and
>> >>> update it with the relevant network (profile).
>> >>
>> >> I thought we allow to change the logical network at vm creation since
>> >> instance types were added?
>> >
>> > Not on API level. In webadmin/userportal you can do it in one go, but
>> that anyway triggers two different actions.
>> >
>> > But now as I have tried it, if I create a VM from template or instance
>> type (using API), the NICs are completely ignored.
>> > It does not matter if template or instance type since instance types
>> just inherit the behavior of the templates so are inheriting also the
>> bug/missing logic etc.
>> >
>> > For me it seems like a bug but not sure. Is there a reason why the NICs
>> are ignored when the VM is created from a template with NICs using API?
>> > What I think is that since the NIC can have different profiles assigned
>> and this can be edited on the FE, this functionality of sending different
>> profile for the specific NIC is just not implemented on API level, so the
>> API just
>> > completely ignores the NICs.
>> > What do you think Lior?
>> >
>> >
>>
>> If I correctly understand what you mean, then that is the current
>> "intended" behavior - supplying NICs as part of VM creation isn't
>> supported, and there's this RFE to support it:
>> https://bugzilla.redhat.com/show_bug.cgi?id=999969
>>
>> My two original suggestions will apparently have to suffice until this
>> RFE is realised; either properly configuring the template's NICs before
>> VM creation or modifying the VMs' NICs following creation.
>>
>> >>
>> >>>
>> >>> Hope this helps! Let us know please :)
>> >>> Yours, Lior.
>> >>>
>> >>> On 01/10/14 10:32, Morgan McLean wrote:
>> >>>> Hi,
>> >>>>
>> >>>> Trying to remotely spawn a large amount of VM's. It would appear I
>> can
>> >>>> only use templates...which would have a NIC stuck to one network
>> vlan.
>> >>>> It doesn't appear that I can change that vlan remotely.
>> >>>>
>> >>>> Is there any easy way I can get this done?
>> >>>>
>> >>>> Thanks,
>> >>>> Morgan
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> Users mailing list
>> >>>> Users at ovirt.org
>> >>>> http://lists.ovirt.org/mailman/listinfo/users
>> >>>>
>> >>> _______________________________________________
>> >>> Users mailing list
>> >>> Users at ovirt.org
>> >>> http://lists.ovirt.org/mailman/listinfo/users
>> >>>
>> >>
>> >> _______________________________________________
>> >> Users mailing list
>> >> Users at ovirt.org
>> >> http://lists.ovirt.org/mailman/listinfo/users
>> >>
>>
>
>
> --
> Thanks,
> Morgan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20141002/902f42be/attachment-0001.html>