Page 1 of 1
CHR features from tool packages
Posted: Fri Oct 09, 2015 12:31 pm
by janisk
Since it is not possible to set up any kind of 3rd party VMS tool packages as a whole in CHR image we can try to at least get some of them to work without having the tools themselves. What exact features you would like to see?
For example:
make guest receive time from the host
make guest react to host sending shutdown signal.
Re: CHR features from tool packages
Posted: Fri Oct 09, 2015 6:10 pm
by boen_robot
You mean like Virtualbox's guest add-ons?
I'd like some sort of clipboard and drag&drop support, whereby I can paste/drop a file from the host to the guest. Right now, to do that you have to connect to the guest from FTP or Winbox - not as convenient as doing it directly via the VM window.
The ability to resize the screen might also be nice, so that in the end, the VM window is like just another terminal window.
Re: CHR features from tool packages
Posted: Sat Oct 10, 2015 12:46 am
by marrold
ACPI shutdown is a big one for me.
Re: CHR features from tool packages
Posted: Sat Oct 10, 2015 11:28 am
by Sanity
I second that. As a Hyper-V user I would like all non-desktop related Hyper-V elements to work. Particularly:
* Obviously integrated network adapters. No need to work with the awfully slow (Interrupt intensive) simulated hardware.
* Shutdown requests. Basically: It must behave to requests from the host. We run our own rented hardware and if the data center goes through the racks and initiated shutdowns (happens rarely, but happened like last weekend - announced Sunday downtime for major component replacement on the power distribution) then I do not expect the virtual router to hang the host shutdown.
* Time service. This way there is no need to set up any SNTP and the router is always in sync with the hosts.
Not sure about the storage side. I mean, it is NICE, but RouterOS is not exactly particularly IO heavy.
I can totally live without dynamic memory.
Re: CHR features from tool packages
Posted: Sun Oct 11, 2015 9:31 am
by bajodel
* Obviously integrated network adapters. No need to work with the awfully slow (Interrupt intensive) simulated hardware.
* Shutdown requests. Basically: It must behave to requests from the host. We run our own rented hardware and if the data center goes through the racks and initiated shutdowns (happens rarely, but happened like last weekend - announced Sunday downtime for major component replacement on the power distribution) then I do not expect the virtual router to hang the host shutdown.
* Time service. This way there is no need to set up any SNTP and the router is always in sync with the hosts.
Not sure about the storage side. I mean, it is NICE, but RouterOS is not exactly particularly IO heavy.
I can totally live without dynamic memory.
+1
Re: CHR features from tool packages
Posted: Tue Oct 13, 2015 11:59 am
by janisk
* Obviously integrated network adapters. No need to work with the awfully slow (Interrupt intensive) simulated hardware.
probably I am missing something but can you elaborate what is this? And how they differ from virtual interfaces that we can create now for Hyper-V guests? (you can use either legacy or just simple network interface in Hyper-V)
Re: CHR features from tool packages
Posted: Tue Oct 13, 2015 12:13 pm
by Sanity
The simulated hardware in Hyper-V is quite - ancient. It is EXTREMELY Interrupt heavy. This makes them extremely unsuitable for high throughput scenarios.
The virtual NIC's that have drivers are modern designs. They do not rely on an interrupt (per byte or something like that) to push the data, meaning that they are a LOT less taxing in high throughput scenarios.
CHeck
http://www.altaro.com/hyper-v/hyper-v-v ... nd-sr-iov/ for a good read up.
Concrete - the simulated hardware is a DEC 21140. We talk of something done in the time 100mbit was considered FAST. Hit it with the loads you may see in a datacenter environment - or even with the requirment to process a 20mbit or more feed without using up too many hardware ressources on the host - and it is a fail.
Re: CHR features from tool packages
Posted: Wed Oct 14, 2015 9:24 pm
by mavink
Virtio drivers for Xen environments. Especially the disk drivers, many cloud hosters use Xen but don't support IDE emulation.
Re: CHR features from tool packages
Posted: Thu Oct 15, 2015 12:19 am
by bakergt
For me, its only shutdown control that we need. Everything else is there. No shutdown control will make running these on smaller sites impossible.
Re: CHR features from tool packages
Posted: Thu Oct 15, 2015 11:35 am
by janisk
Virtio drivers for Xen environments. Especially the disk drivers, many cloud hosters use Xen but don't support IDE emulation.
Virtio is supported. And it is not tools related.
Regarding IO-SRV - it is on our to-do list.
Posted: Wed Nov 18, 2015 5:48 pm
by Hammy
What is preventing you from integrating the third-party management tools?
Sent from my Nexus 6 using Tapatalk
Re: CHR features from tool packages
Posted: Tue Nov 24, 2015 11:48 am
by JnSchl
Personally I think it would be great to get the MikroTik CHR working in XenServer environments. With XenServer you get great functionality for free (and it’s easy to deploy). XenServer with CHR instances in combination with MikroTik devices would be a very powerful virtualization environment.
The following features of each hypervisor type should be available for CHR:
• CPU utilization
• Memory metering
• Disks usage
• Network utilization
• Live migration
• Shutdown & Restart
• Support for network interfaces
Priority of supported hypervisors for CHR from my point of view:
1. XenServer (free -
http://xenserver.org/ | commercial support available from Citrix)
3. VMware
4. Hyper-V
5. KVM
6. Xen Project
Re: CHR features from tool packages
Posted: Tue Dec 08, 2015 9:35 am
by benzieb
* Time service. This way there is no need to set up any SNTP and the router is always in sync with the hosts.
Off topic, just wanted to make a quick comment on this one: most hypervisors are pretty tough on the internal clock. We've found our Hyper-V servers (and ESX before them) tended to drift around a bit depending on system load. Our environment (SCADA) is very sensitive to clock clock changes. We disabled timesync on all of our VMs (easy to do in bulk via powershell):
Disable-VMIntegrationService -name 'Time Synchronization' -Computername HYPERVHOST -Vmname *
and then plonked this registry entry on our guest VMs so they could sync directly against our timesource via NTP/SNTP.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Parameters]
"Type"="NTP"
"NtpServer"="ntpserver.domain,0x1"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Config]
"AnnounceFlags"=dword:00000005
"MaxNegPhaseCorrection"=dword:00000708
"MaxPosPhaseCorrection"=dword:00000708
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\TimeProviders\NtpServer]
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\TimeProviders\NtpClient]
"SpecialPollInterval"=dword:0000012c