Skip to content
This repository has been archived by the owner on May 12, 2021. It is now read-only.

QMP command failed: 'pc-dimm' is not a valid device model name #1245

Closed
umarcor opened this issue Feb 18, 2019 · 9 comments
Closed

QMP command failed: 'pc-dimm' is not a valid device model name #1245

umarcor opened this issue Feb 18, 2019 · 9 comments

Comments

@umarcor
Copy link

umarcor commented Feb 18, 2019

Description of problem

~$ docker run --rm -it alpine ls
bin    etc    lib    mnt    proc   run    srv    tmp    var
dev    home   media  opt    root   sbin   sys    usr

~$ docker run --rm -it --runtime=runc alpine ls
bin    etc    lib    mnt    proc   run    srv    tmp    var
dev    home   media  opt    root   sbin   sys    usr

~$ docker run --rm -it --runtime=kata-runtime alpine ls
bin    etc    lib    mnt    proc   run    srv    tmp    var
dev    home   media  opt    root   sbin   sys    usr

~$ docker run --rm -it --runtime=runc -m 1g alpine ls
WARNING: Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap.
bin    etc    lib    mnt    proc   run    srv    tmp    var
dev    home   media  opt    root   sbin   sys    usr

~$ docker run --rm -it --runtime=kata-runtime -m 1g alpine ls
WARNING: Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap.
docker: Error response from daemon: OCI runtime create failed: QMP command failed: 'pc-dimm' is not a valid device model name: unknown.

Expected result

I expected kata-runtime to accept option -m.

Actual result

The following error is shown: docker: Error response from daemon: OCI runtime create failed: QMP command failed: 'pc-dimm' is not a valid device model name: unknown.


kata-collect-data.sh is not found on the host.

~$ kata-containers.runtime kata-check
INFO[0000] Unable to know if the system is running inside a VM  source=virtcontainers
INFO[0000] kernel property found                         arch=arm64 description="Kernel-based Virtual Machine" name=kvm pid=13725 source=runtime type=module
INFO[0000] kernel property found                         arch=arm64 description="Host kernel accelerator for virtio" name=vhost pid=13725 source=runtime type=module
INFO[0000] kernel property found                         arch=arm64 description="Host kernel accelerator for virtio network" name=vhost_net pid=13725 source=runtime type=module
INFO[0000] System is capable of running Kata Containers  arch=arm64 name=kata-runtime pid=13725 source=runtime
@grahamwhaley
Copy link
Contributor

Hi @umarcor - I guess you are running this on an ARM platform?
Could you post the output of kata-runtime kata-env here for us for some reference pls?
I'll /cc @Pennyzct in from the ARM side of things.
thanks for reporting!

@devimc
Copy link

devimc commented Feb 18, 2019

cc @Weichen81

@umarcor
Copy link
Author

umarcor commented Feb 18, 2019

Hi @umarcor - I guess you are running this on an ARM platform?

Yes, this is a APM X-Gene 2, 64-bit (ARMv8.0-A) octa-core by AppliedMicro. It has 32GB of RAM, and no swap.

Could you post the output of kata-runtime kata-env here for us for some reference pls?

~$ kata-containers.runtime kata-env
[Meta]
  Version = "1.0.20"

[Runtime]
  Debug = false
  Trace = false
  DisableGuestSeccomp = true
  DisableNewNetNs = false
  Path = "/snap/kata-containers/33/usr/bin/kata-runtime"
  [Runtime.Version]
    Semver = "1.5.0"
    Commit = "5f7fcd773089a615b776862f92217e987f06df0a-dirty"
    OCI = "1.0.1-dev"
  [Runtime.Config]
    Path = "/snap/kata-containers/33/usr/share/defaults/kata-containers/configuration.toml"

[Hypervisor]
  MachineType = "virt"
  Version = "QEMU emulator version 2.11.0\nCopyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers"
  Path = "/snap/kata-containers/33/usr/bin/qemu-system-aarch64"
  BlockDeviceDriver = "virtio-scsi"
  EntropySource = "/dev/urandom"
  Msize9p = 8192
  MemorySlots = 10
  Debug = false
  UseVSock = false

[Image]
  Path = ""

[Kernel]
  Path = "/snap/kata-containers/33/usr/share/kata-containers/vmlinuz-4.14.67.container"
  Parameters = ""

[Initrd]
  Path = "/snap/kata-containers/33/usr/share/kata-containers/kata-containers-initrd.img"

[Proxy]
  Type = "kataProxy"
  Version = "kata-proxy version 1.5.0-9e77a0b1925d1ab3afda7d46ec256be8a9cff222"
  Path = "/snap/kata-containers/current/usr/libexec/kata-containers/kata-proxy"
  Debug = false

[Shim]
  Type = "kataShim"
  Version = "kata-shim version 1.5.0-efbf3bb25065ce89099630b753d218cdc678e758"
  Path = "/snap/kata-containers/33/usr/libexec/kata-containers/kata-shim"
  Debug = false

[Agent]
  Type = "kata"

[Host]
  Kernel = "4.9.0-8-arm64"
  Architecture = "arm64"
  VMContainerCapable = true
  SupportVSocks = false
  [Host.Distro]
    Name = "Debian GNU/Linux"
    Version = "9"
  [Host.CPU]
    Vendor = "3rd Party Limited"
    Model = "v8"

[Netmon]
  Version = "kata-netmon version 1.5.0"
  Path = "/snap/kata-containers/current/usr/libexec/kata-containers/kata-netmon"
  Debug = false
  Enable = false

thanks for reporting!

Thank to you for having a look at it. Please, let me know whether I can provide any further info or run any other test.

@Pennyzct
Copy link
Contributor

Hi~ @umarcor Sorry for the missing feature on ARM Platform. For now, -m flag hasn't been supported on arm, but we have pulled related request agent/#443, packaging/#309, runtime/#1152 to gap the hole.
Some got merged, some under review. I will keep you updated! ;)

@umarcor
Copy link
Author

umarcor commented Feb 19, 2019

Thanks @Pennyzct! Nonetheless, this is not critical for me. I found it incidentally, as kata was setup as the default runtime in this specific server and that broke some existing builds. I am using runc for now, until the PRs you mentioned are merged.

BTW, do you think that the clock skew issue mentioned there is worth a separate issue here?

@Pennyzct
Copy link
Contributor

Pennyzct commented Feb 19, 2019

Hi~@umarcor Could you please offer specific bug info about clock skew ? ;). Early days, we once encountered related issue, grab the discussion here,

The time in container is inconsistent with the time in host, which i think it should be the same in default.

  • host
root@testing-1:~# date
Wed Nov  7 16:37:01 CST 2018
  • container
root@testing-1:~# docker run -it ubuntu
root@14834c3b0c89:/# date
Mon Mar  5 22:16:43 UTC 2018
 root@testing-1:~# docker run -it alpine
/ # date
Mon Mar  5 22:16:43 UTC 2018

I have tried multiple images, such like alpine, ubuntu, etc, it share the same output.
Even when i tried to cover the /etc/localtime with the one in host, it couldn't been interpreted correctly.

root@testing-1:~# docker run -it -v /etc/localtime:/etc/localtime:ro ubuntu
root@f6d9f22653c3:/# date
Tue Mar  6 06:16:43 CST 2018

and we have already resolved it with this PR packaging#239. So if you use the default kernel config provided by kata, you shouldn't meet above errors. ;)

@umarcor
Copy link
Author

umarcor commented Feb 19, 2019

Hi~@umarcor Could you please offer specific bug info about clock skew ? ;).

The issue is related to building either ghdl/ghdl or DynamoRIO/dynamorio by running either make -j or make -j$(nproc). Lots of messages as the following are shown and the build fails:

  • Clock skew detected. Your build may be incomplete.
  • Warning: File <file> has modification time 0.008 s in the future

If I execute make instead, or if I limit nproc through --cpuset-cpus so that a single core is used, builds are successful. So, this seems not to be a problem with time between the container and the host, but between multiple taks being executed in different cores (all of them in the container/VM).

@Pennyzct
Copy link
Contributor

Hi~@umarcor so sorry for the delay.
The flag --cpuset-cpus isn't applied for kata containers on arm64, since the underlying technique is based on cpu hotplug via acpi, which isn't applicable on arm.
And based on default qemu flag, -smp 1,cores=1,threads=1,sockets=1,maxcpus=123, we only provide one vcpu for container/VM on arm. so if you are running make -j$(nproc) in kata container/VM, that's quite the same thing as make -j1 .
when you switch to runc, does above errors still occur?

@umarcor
Copy link
Author

umarcor commented Feb 28, 2019

@Pennyzct, I opened #1293 to discuss the issue with make.

We can keep this issue open until -m is supported on ARM, or close it already.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants