It looks like should not be hard to implement
https://www.kuncar.net/blog/using-vconfig-to-set-vlan-tagged-interface-with-802-1p-cos-priority-bits-set/2014/

Awsome!!

I confirmed 4.4.0-1+vyos2+current1 iproute and iproute2 packages in the image. Thanks!

updated package name to iproute2
created dummy package iproute
changed depends for vyatta/vyos packages to iproute2

@UnicronNL Thank you.

@higebu I think the build process picks the debian jessie upstream version over our version, I'll dive in to this

Why we build only "iproute" package now? I guess we should build both "iproute" and "iproute2". And current iso includes debian packages.
Current iproute and iproute2 version is here:

I'd certainly be willing to try whatever is necessary and test it out.

https://github.com/vyos/vyatta-iproute/commit/1f6e71a2b12599ba6c1f53c1e75a6cc036b2a0ac

@syncer UnicronNL added open-vm-tools into iso with this commit: https://github.com/vyos/vyos-world/commit/ecae4cb98704f86b16a5a9935f94fcb6a996326f.
So I removed installing open-vm-tools process from 'build-vmware-image'.
My testing images are here: https://github.com/higebu/vyos-build/releases/tag/1.2.0-higebu5.

It`s clear now! Thanks again!

Thank you. I have updated snmp on my vyos right now, need to wait an hour or so and i will let you know. Thanks again!

updated the source: https://github.com/vyos/net-snmp/commit/13458add4bd09ff4207e20a07990f72821a696f4
package location: http://dev.packages.vyos.net/vyos/pool/main/n/net-snmp/

From what I understand from reading up on this, the "truncating" issue occurs when a 32bit value is being returned on a 64bit system.

Seems to be ok, thanks!

I will make it like this... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597024

Thank you, now there is another error/warning. I don`t know if this is connected with this case or not:

Packages are updated:
http://dev.packages.vyos.net/vyos/pool/main/n/net-snmp/

@paszczus I forgot to remove the old lines... I will build again... will be done shortly.

I have upgraded to newer version but there is still same error:

will fix!

The diff on the patch https://github.com/vyos/net-snmp/commit/01043209782cb786696e4dc20b9468e97d4f4acd

I applied patch from redhat:
https://github.com/vyos/net-snmp/commit/01043209782cb786696e4dc20b9468e97d4f4acd

https://github.com/vyos/vyos-world/commit/ecae4cb98704f86b16a5a9935f94fcb6a996326f

Any updates with this case?

@EwaldvanGeffen advanced ova should work just fine,
it's just like simple ova, but making questions upon deploy
I will test to be sure for 100% and will report back

By duplicate address detection you mean (examples cases):

1. eth0 address 192.168.1.1/24 and eth0 address 192.168.1.1/25
2. as 1) but between eth0 and eth1
3. duplicate IP address on connected segment of interface (you share an IP with another node)
4. as 3) but with all connected-segments
5. as 4) but additionally in connected routes unique

Can you deploy the advanced ova on free products? Because iirc there are some restraints (eg. single node ESXi)?

@syncer Sorry, I already added support for signed ovf to current branch, but didn't upload my ovf.
And we should rebuild open-vm-tools for VyOS kernel header as T16. I'll tryed to add the rebuild step to OVF build process.

@higebu i think we need to add also signed ovf
ova is great for offline distribution and ovf can be deployed online from within vSphere Client or vCloud Director web

So we currently preparing with @higebu simple signed ova/ovf
once migration to jessie will be finished, we can then think about advanced version

Same issue here on 1.1.7, vmxnet3 interfaces

Interesting, we'll look into merging it.

@murmaider thank for pointing to this!

Looks like Centos created a patch for this - https://git.centos.org/blob/rpms!net-snmp/8a419fd557adfdc5e6efd8977f5fb7de7fa36f9f/SOURCES!net-snmp-5.7.2-dot3stats-log.patch

I have upgraded VyOs to 1.1.7 yesterday but there is same problem.

Happy to test, what are the current known problems?

There is a probleme with SNMP when ixgbe on Intel 82599EB are used.
There are many messages in logs like:

Can you please transfer original content from forum,
and also if possible, collect and attach logs here
Thanks!

Yes, we can add it to build process with ovfool.
How about "current" image from http://dev.packages.vyos.net/iso/current/amd64/ ?

can we add signing to build process?(we most probably will need to use ovftool for that)
ovftool will be useful also for ova generation.
Also it looks like that VMWare Fusion produce more slim image

@syncer OK. I'll fix them.

@higebu proposing remove sound device and usb controller and make 1GB Ram by default

@syncer I uploaded my image on GitHub: https://github.com/higebu/vyos-build/releases/tag/1.2.0-higebu1

@higebu lets do it other linux than

IMHO, other linux is better than Debian, because VyOS is not Debian.

@higebu on some earlier vCloud Director setups OS limiting selection of network cards type(e.g. VMXNET3) but maybe it's not the case now, I will try on vCloud Air your image when it's ready

@syncer vSphere 5.0 doesn't reach EOS, but I think we can keep HW version 9 too. Why do you want to use Debian 6 as OS?

In T14#211, @higebu wrote:

I tested it on vSphere 6.0 and it works fine! Also I changed the osType to other26xLinux64Guest for old version of vSphere.

Not sure if we can keep HW version 9 and Debian 6 as OS(just wondering)? this for vSphere 5.1 and later, any reason to support earlier versions?

I tested it on vSphere 6.0 and it works fine! Also I changed the osType to other26xLinux64Guest for old version of vSphere.

The OVF built on my machine works fine on VMware Workstation 12. I'll test on ESXi soon.

I pushed the fix.

Please push the accelerator fix, then I can configure Jenkins accordingly.

@dmbaturin It looks good how it is. so i do see why to change it.

Removed the package repos from packages.vyos.net. I also moved the makeself-based update packs to dev.packages.vyos.net/legacy, it's unlikely that anyone wants them anymore, as they are ancient.
Next step is the repo for independent packages and ckeaning them up from the /vyos repo.

@UnicronNL Do you think we should redo the vyos-build job this way too?

@dmbaturin I used cron jubs calling the build url...
its in /etc/cron.d/build-isos

Looks like the cron schedule setup from the web UI worked. Closing now, we can improve it later.

Fixed the jenkins job (https://ci.vyos.net/job/vyos-build) and set it to run every day at 02:00. We'll see if it works tomorrow.
The builds are at http://dev.packages.vyos.net/iso/current/amd64/

Now it works again. The format is a bit different from original: