KVM support with vSRX

[gtrxcbdev]

Is there any known reason why this module would not work with vSRX on a /dev/pts device? I can boot a vSRX in KVM and it operates just fine, and I am able to connect to the pts device outside of virsh (see below). When I attempt to run netconify it gets to the loading configuration portion and then just hangs until I break out of the program witch yields a trace, after which if I attempt to connect to the console again I receive no response and the only way to reestablish communications is to force a shutdown on the vSRX and boot new and fresh.

Connecting to console via virsh

root@test:~# virsh start vsrx-test --console

Domain vsrx-ansible1 started
Connected to domain vsrx-ansible1
Escape character is ^]
Consoles: serial port  
BIOS drive C: is disk0
BIOS 639kB/2096120kB available memory
.......
.......
.......
Sep  6 04:29:51 init: multicast-snooping (PID 1128) started
Sep  6 04:29:51 init: license-service (PID 1129) started
Sep  6 04:29:51 init: service-deployment (PID 1130) started
Sep  6 04:29:51 init: Starting of initial processes complete

Amnesiac (ttyd0)

login:

Connecting directly to pts device.

root@test:~# screen /dev/pts/`ls -lh /dev/pts | grep libvirt-qemu | awk '{print $10}'`

Amnesiac (ttyd0)

login:

Running netconify

root@test:~# netconify -f srx-test-config.txt -p /dev/pts/`ls -lh /dev/pts | grep libvirt-qemu | awk '{print $10}'`
TTY:login:connecting to TTY:/dev/pts/3 ...
TTY:login:logging in ...
TTY:login:starting NETCONF
conf:loading into device ...

Ctrl-C after 60m+ of waiting

^CTraceback (most recent call last):
  File "/usr/local/bin/netconify", line 5, in <module>
    pkg_resources.run_script('junos-netconify==1.0.1', 'netconify')
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 528, in run_script
    self.require(requires)[0].run_script(script_name, ns)
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 1401, in run_script
    exec(script_code, namespace, namespace)
  File "/usr/local/lib/python2.7/dist-packages/junos_netconify-1.0.1-py2.7.egg/EGG-INFO/scripts/netconify", line 6, in <module>

  File "build/bdist.linux-x86_64/egg/netconify/cmdo.py", line 233, in run
  File "build/bdist.linux-x86_64/egg/netconify/cmdo.py", line 334, in _do_actions
  File "build/bdist.linux-x86_64/egg/netconify/cmdo.py", line 415, in _push_config
  File "build/bdist.linux-x86_64/egg/netconify/tty_netconf.py", line 75, in load
  File "build/bdist.linux-x86_64/egg/netconify/tty_netconf.py", line 164, in rpc
  File "build/bdist.linux-x86_64/egg/netconify/tty_netconf.py", line 175, in _receive
  File "build/bdist.linux-x86_64/egg/netconify/tty_serial.py", line 66, in read
  File "/usr/local/lib/python2.7/dist-packages/serial/serialposix.py", line 461, in read
    ready,_,_ = select.select([self.fd],[],[], self._timeout)

[r2600r]

The issue my be from the return netconf.py is receiving. Regarding "I receive no response and the only way to reestablish communications is to force a shutdown on the vSRX and boot new and fresh" -- since there is no echo in NETCONF over ssh, you do not see command or output on console. Next time press enter couple of time and the type either or <>. One of these will trow error and session should return back to cli.

[gtrxcbdev]

This is not being done over SSH, this is being done directly on a serial port in this case when KVM boots the vSRX it dynamically creates a PTS port you can connect to for console access (hence the awkward ls/grep/awk command since I know no way of specifying this statically). In this particular case it was being done on /dev/pts/3 (not sure what the default rate is, but assume 9600 as with a standard direct physical device connection, though I have tried specifying other rates with the -b option)

That being said I have tried pressing enter/return a few times with no results, just get a next line in the terminal window, I have not tried using "<" or ">", so I will give that a try and see if that moves things along, but longer term this would probably limit automating the netconify tool to bootstrap vSRX deployments short of mounting the extracted image and replacing the default configuration, which would have to be done for every version of the image used in production.