Catalyst 8300 - Virtual Service will not activate after code upgrade

[Stephanie Tingey]

Hey,

I have a catalyst 8300 router and I upgraded the code from 17.09.04a to 17.13.1a.  Now my ubuntu kvm virtual service will not activate.  I've uninstalled and attempted to reinstall the ova file, i even tried an earlier version i created that i know worked fine on earlier code.  Here's the debug from the install and activation:

VIRTUAL-SERVICE [PlexShark]: Sending install req for [PlexShark], path=harddisk:/plexoriginal.ova, uri= uid=1

Jan 27 09:09:32.313: VIRTUAL-INSTANCE: Message sent for INSTALL TDL request: Virtual-instance name: PlexShark, UID: 1VIRTUAL-SERVICE: Started response timer for tid 99000006 - 30 minutes

Teurerouter#
Jan 27 2024 02:09:47.367 GMT: %VMAN-5-PACKAGE_SIGNING_LEVEL_ON_INSTALL: R0/0: vman: Package 'plexoriginal.ova' for service container 'PlexShark' is 'unsigned', signing level cached on original install is 'unsigned'
Teurerouter#VIRTUAL-SERVICE: Install response handler: VM[PlexShark]: Owner IOSd trans_id 2566914054
VIRTUAL-SERVICE [PlexShark]: vm[PlexShark] set owner [IOSd] pkg_path [/vol/harddisk/plexoriginal.ova]
VIRTUAL-SERVICE [PlexShark]: application_name: 'ubuntu' application_vendor: '' application_version: '1.1'
VIRTUAL-SERVICE [PlexShark]: Default profile info: license_name: '', license_ver: ''
VIRTUAL-SERVICE: Install pkg response for tid 99000006: rc=0, descr=Install Success
VIRTUAL-SERVICE [PlexShark]: License type: none, no license needed

Jan 27 2024 02:10:00.308 GMT: %VIRT_SERVICE-5-INSTALL_STATE: Successfully installed virtual service PlexShark
Teurerouter#VIRTUAL-SERVICE: Received local transport activation request
VIRTUAL-SERVICE: Enabling vman local transport
VIRTUAL-SERVICE: Local transport 'activation' request processed

Teurerouter#VIRTUAL-SERVICE [PlexShark]: Activate CLI: appl->owner [IOSd]

Jan 27 09:10:20.088: VIRTUAL-INSTANCE: Message sent for ACTIVATE TDL request: Virtual service name: PlexShark, UID: 1VIRTUAL-SERVICE [PlexShark]: Started virtual service (1) activate response timer - 30 minutes

Teurerouter#
Jan 27 2024 02:10:23.035 GMT: %VMAN-2-START_FAILED: R0/0: vman: Virtual Service[PlexShark]::Start failed::Failed to start the virtual service
Teurerouter#VIRTUAL-SERVICE: clnt_type 0: Interface counter is '1'
VIRTUAL-SERVICE: Information for virtual port grp '0' is received
VIRTUAL-SERVICE [PlexShark]: Deliver intf response, vm =PlexShark, counter=1
VIRTUAL-SERVICE [PlexShark]: Received interface id=0, type=1, state=0
VIRTUAL-SERVICE [PlexShark]: Received virtual port group interface 0 with service MAC 44b6.be91.7eae, state: down

Jan 27 09:10:26.177: VIRTUAL-INSTANCE: Message sent for IF MTU TDL message: appliance 'PlexShark'VIRTUAL-SERVICE [PlexShark]: Activate response handler: rsp_rc 1
VIRTUAL-SERVICE [PlexShark]:
Deliver response: appliance_state 3 rsp_rc 1 if_notify name PlexShark clnt_type 0 act_state 1

Jan 27 2024 02:10:26.177 GMT: %VIRT_SERVICE-5-ACTIVATION_STATE: Failed to activate virtual service PlexShark
Teurerouter#VIRTUAL-SERVICE [PlexShark]: Stopped virtual service (1) response timer
VIRTUAL-SERVICE: Delivered Virt-manager response message to virtual service 'PlexShark' - Response: 'FAIL'

Current configuration : 205 bytes
!
interface VirtualPortGroup0
ip address 10.0.0.1 255.255.255.248
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat inside
zone-member security ZBFW_inside
no mop enabled
no mop sysid
end

virtual-service
signing level unsigned
!
!
virtual-service PlexShark
vnic gateway VirtualPortGroup0

[tanzeelqbtech]

Thanks for sharing the details. Your understanding is broadly correct: app-hosting and virtual-service are different virtualization mechanisms, and the distinction around the kernel is important.

With app-hosting/GuestShell, the container shares the host kernel, so you can't treat it like a completely independent VM with its own guest kernel. A virtual-service deployment using a supported OVA/VM image is intended for a more traditional virtual-machine model where the guest OS has its own kernel.

I haven't personally validated a Windows guest on this exact platform/software combination, though, so I would be careful about assuming that because the virtual-service mechanism supports a VM, every Windows image is supported. Cisco's platform and IOS XE release documentation would be the final authority on supported guest OSes and image formats.

Your OVA construction is interesting as well. Since you're creating the archive manually rather than using ioxclient, I'd specifically verify the manifest/checksum files and the exact OVA structure expected by the IOS XE version. A package can be a valid tar archive but still be rejected if the manifest, filenames, checksums, or descriptor don't match what virtual-service expects.

If you can share the exact IOS XE release and platform you're testing on, along with the output of the virtual-service installation/status commands, it would be easier to determine whether the issue is the OVA structure or a platform limitation.