nanovms / ops

ops - build and run nanos unikernels

Home Page:https://ops.city

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

failing to mount volume in unikernel

zeroecco opened this issue · comments

my ops based on master branch for the proxmox features recently added:

rich@development:~/unikernels$ ops profile
Ops version:
Nanos version: 0.1.42
Qemu version: 6.2.0
Arch: linux
Virtualized: true

my ops config:

{
  "Args": [
    <redacted>
  ],
  "Dirs": [
    "files/"
  ],
  "BaseVolumeSz": "750m",
  "CloudConfig" : {
    "ImageName": "lighthouse",
    "Flavor": "c6a.2xlarge",
    "Platform" :"aws",
    "ProjectID" :"lighthouse",
    "Zone": "us-east-1a",
    "VPC": "redacted",
    "SecurityGroup": "<redacted>",
    "BucketName":"<redacted>"
  },
  "RunConfig": {
    "Ports": [
      "5052"
      ]
  },
  "Mounts":{
    "<redacted>": "/data"
  }
}

commands ran in order:

ops instance create lighthouse -t aws -c config.ops
ops volume create data -c config.ops -t aws -s 128g
ops volume attach lighthouse-<some_number> data -t aws -c config.ops

after instance in AWS starts I get this error:

kvm_detect error: found signature but unrecognized features cpuid 0x40000010; check KVM version?en1: assigned 10.0.1.243
volume_link error: cannot mount filesystem: (result:unknown frame identifier 0x0)

Screen Shot 2022-09-20 at 3 53 27 PM
screenshot from the nightly build

I tried to reproduce the issue, but was unable to. I built ops from the master branch and used it to create a test image, an empty volume (same 128GB size as yours) and run an instance (same availability zone and same instance type). When I attach the volume to the instance, it is mounted correctly. I tested with both attaching the volume to an already running instance, and starting the instance with the volume already attached; in both cases, the volume is mounted correctly.
From your logs it looks like some kind of filesystem corruption happened. Did the issue occur when attaching a newly created volume on a newly created instance, or did it happen after stopping and restarting the instance, or after detaching and reattaching the volume?

just restarting the instance let to this failure. I ended up abandoning running sigp/lighthouse on unikernels for the moment so I do not have any additional information at this time. I will close this issue as user error