kubevirt: kubevirt it takes too long to start the window vm
What happened: kubevirt it takes too long to start the window vm( spent at least 4 minutes)
What you expected to happen: How to optimize to reduce startup time?
How to reproduce it (as minimally and precisely as possible): windows.yaml:
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstance
metadata:
labels:
special: vmi-windows
name: vmi-windows
spec:
domain:
clock:
timer:
hpet:
present: false
hyperv: {}
pit:
tickPolicy: delay
rtc:
tickPolicy: catchup
utc: {}
cpu:
cores: 2
devices:
disks:
- disk:
bus: virtio
name: cloudinitdisk
interfaces:
- bridge: {}
model: e1000
name: default
features:
acpi: {}
apic: {}
hyperv:
relaxed: {}
spinlocks:
spinlocks: 8191
vapic: {}
firmware:
uuid: 5d307ca9-b3ef-428c-8861-06e72d69f223
machine:
type: q35
resources:
requests:
memory: 2Gi
networks:
- name: default
pod: {}
terminationGracePeriodSeconds: 0
volumes:
- name: cloudinitdisk
containerDisk:
image: www.myregistry.com:5000/kube-win7:latest
kubectl create -f windows.yaml
#It takes 4 minutes to start
Environment:
- KubeVirt version v0.17.0
- Kubernetes version v1.13.5
Thanks in advance.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 52 (30 by maintainers)
@yinjingjiu yes, I am currently implementing an improved version of #1565 which should also be backward compatible to not break old container disks.
@yinjingjiu It can still be that your long boot time is because of the initial copy of the disk on every VMI start. We can rule that out by e.g. copying the windows image on a host path, and then boot from there via a
hostDisk. If that is sufficiently fast, we know it is because of the initial copy. We can then revive some efforts like #1565, to get rid of this one-time-copy issue. @davidvossel FYI.@yinjingjiu we got a request for pull policy configuration recently from someone else too. Let me prepare a change.