+1 for KVM - just make sure to have vmware tools / drivers installed
properly (virtio for KVM)
On 14 May 2018 at 19:19, Simon Weller wrote:
> On KVM, selecting the "Windows PV" OS type will work fine with Windows
> Server 2016. Might be worth trying on vmware.
>
>
>
Hi,
@rhtyd, I checked the PR changes. Good that the agent is not waiting for
the pending jobs and retrying connection to management server. This might
have impact on ssvm and kvm agent tasks, not much on cpvm. Any sync or
cleanup mechanism for Volumes/VMs to address the failed/pending agent jobs
On KVM, selecting the "Windows PV" OS type will work fine with Windows Server
2016. Might be worth trying on vmware.
From: Rafael Weingärtner
Sent: Monday, May 14, 2018 11:06 AM
To: dev
Cc: users
Subject: Re: Cloudstack compatiblity
There is one extra detail. If your hypervisor version does not support the
OS you want to use, there is no magic ACS can do.
Therefore, first you need to make sure your hypervisor supports the OS you
want. Then, you need to see if you have a guest OS entry for the OS you
want to use, and if this
Hi Marc,
It seems the compatibility table with Cloudstack version and OS guest
versions is not listed. May be you can try with db query using version
(updated column) and guest_os_hypervisor (created column) tables.
Please check the current version OS compatibility using *listGuestOsMapping*
API
Correct about the thread context, so if the answer is coming into a
management server that doesn't have the context and drops it, it should be
fine then. The PR is then already a good improvement to let the agent
reconnect even when it's doing a long processing request, so it can keeps
on
Hi all!
I am using CloudStack 4.9.2 on VMWare hypervisor, and I tried to create a
"Windows Server 2016" OS template but i have some issues working with it,
sometimes network does not work properly.
Do you know if it is not compatible with this version? is there any
compatibility matrix / table
Thanks Marc and Rafael for replying.
In my experimentation, when agent disconnects if will wait for the pending
jobs/task to complete and on completion it creates an Answer instance and tries
to sent it using a `link` which no longer exists and fails. This is current
behaviour, on the mgmt
Hi,
I'm also for a bigger change but this PR already moves forward to a better
agent <-> management connection hanlding.
@rhtyd did you test your PR manually by, for example, requesting a long
snapshot operation and disconnecting the agent.
I have one concern here: when an async job is taken