Could we exec the vm by using kubectl exec if sshd died in the vm?

[weixiao-huang]

I notice the doc using sshd to access the vm. However, I also could use kubectl exec to enter the pod but not the vm. So is there some method to access the vm by using kubectl exec if sshd died?

[fengye87]

@weixiao-huang Yes, there is a way to access the VM via serial console inside the VM pod, but we intentionally not document it since it's not recommended. If you really intend to do that, you could try screen -O -m /dev/pts/0 inside the VM pod.

[shawn111]

@fengye87 Virtink is such a cool project.

I try on my env Kind over podman.
I fellow the quickstart steps

kubectl exec -it vm-ubuntu-container-rootfs-8gpmq -- sh
Defaulted container "cloud-hypervisor" out of: cloud-hypervisor, init-kernel (init), init-volume-ubuntu (init), init-volume-cloud-init (init)
/ # 

/ # ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0-nic@if37: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue master br-eth0 state UP 
    link/ether 1e:fb:64:7f:ff:17 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::1cfb:64ff:fe7f:ff17/64 scope link 
       valid_lft forever preferred_lft forever
3: br-eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 1e:fb:64:7f:ff:17 brd ff:ff:ff:ff:ff:ff
    inet 169.254.200.1/30 brd 169.254.200.3 scope global br-eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::e0ac:1aff:fe0a:f3a9/64 scope link 
       valid_lft forever preferred_lft forever
4: eth0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN 
    link/ether 62:ce:fa:25:c7:dd brd ff:ff:ff:ff:ff:ff
    inet 10.244.0.36/24 brd 10.244.0.255 scope global eth0
       valid_lft forever preferred_lft forever
5: tap-eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-eth0 state UP qlen 1000
    link/ether 32:31:2c:8f:6d:2b brd ff:ff:ff:ff:ff:ff
    inet6 fe80::3031:2cff:fe8f:6d2b/64 scope link 
       valid_lft forever preferred_lft forever

It seems the pod and cloud-hypervisor work.
But network is not connected.
As beginning, eth0 is down.
But even manually turn eth0 up, still cannot connect other pods.

kubectl exec vm-ubuntu-container-rootfs-mdzn9 -it -- /bin/sh

Try screen -O -m /dev/pts/0, does not work, ether.

/ # ps aux
PID   USER     TIME  COMMAND
    1 root      0:00 /sbin/tini -g -- /entrypoint.sh eyJraW5kIjoiVmlydHVhbE1hY2hpbmUiLCJhcGlWZXJzaW9uIjoidmlydC52aXJ0aW5rLnNtYXJ0eC5jb20vdjFhbHBoYTEiLCJtZXRh
   14 root      0:00 {entrypoint.sh} /bin/sh /entrypoint.sh eyJraW5kIjoiVmlydHVhbE1hY2hpbmUiLCJhcGlWZXJzaW9uIjoidmlydC52aXJ0aW5rLnNtYXJ0eC5jb20vdjFhbHBoYTEiL
   23 dnsmasq   0:00 dnsmasq --conf-file=/var/run/virtink/dnsmasq/br-eth0.conf --pid-file=/var/run/virtink/dnsmasq/br-eth0.pid
   24 root      0:07 cloud-hypervisor --api-socket /var/run/virtink/ch.sock --console pty --serial tty --kernel /mnt/virtink-kernel/vmlinux --cmdline console
   28 root      0:00 [vmm]
  203 root      0:00 /bin/sh
  256 root      0:00 ps aux
/ # screen -O -m /dev/pts/0 

## Nothing... A moment been a whole blank screen. can type but no response.

[fengye87]

@shawn111 For the network part, that's the expected behavior in the bridge mode, see this doc for more details.

For the screen -O -m /dev/pts/0 part, the --cmdline console option seems a little bit odd to me, could you post your VM manifest here?

[shawn111]

It is from https://github.com/smartxworks/virtink.

cat <<EOF | kubectl apply -f -
apiVersion: virt.virtink.smartx.com/v1alpha1
kind: VirtualMachine
metadata:
  name: ubuntu-container-rootfs
spec:
  instance:
    memory:
      size: 1Gi
    kernel:
      image: smartxworks/virtink-kernel-5.15.12
      cmdline: "console=ttyS0 root=/dev/vda rw"
    disks:
      - name: ubuntu
      - name: cloud-init
    interfaces:
      - name: pod
  volumes:
    - name: ubuntu
      containerRootfs:
        image: smartxworks/virtink-container-rootfs-ubuntu
        size: 4Gi
    - name: cloud-init
      cloudInit:
        userData: |-
          #cloud-config
          password: password
          chpasswd: { expire: False }
          ssh_pwauth: True
  networks:
    - name: pod
      pod: {}
EOF

[fengye87]

That's a little bit odd. You said there's nothing on the screen after screen -O -m /dev/pts/0, but can type. Did you try typing some Enters here? If pressing enters after the screen command didn't help, could your post the VM pod's log here?

[carezkh]

@shawn111 Actually, the pod NIC eth0 is a dummy interface in bridge mode, we keep it with the pod IP to make it compatible with CRI docker. It's because the CRI call PodSandboxStatus will inspect the real-time network situation in pod netns, without dummy interface eth0 and its pod IP, when using CNI like Calico, the routing rule to this pod IP on host will be lost.