@Zhe can you please update?
This could be because downstream is not supporting SLIRP. It might be that for CNV we need to use the delegateIP option by default. This would mean that we need to make the default network approach configurable.
(In reply to Fabian Deutsch from comment #3) > This could be because downstream is not supporting SLIRP. > > It might be that for CNV we need to use the delegateIP option by default. > This would mean that we need to make the default network approach > configurable. Could you please explain why SLIRP is relevant here? The example file used (vmi-windows.yaml) doesn't use slirp but bridge (with implicit delegateIp = true). Even if it would not specify bridge explicitly, kubevirt will add a default pod interface that is of bridge type.
(In reply to Vladik Romanovsky from comment #6) > It's probably somehow related to dhcp. cirros uses a udhcp, while rhel and > windows have more strict clients. > I am not sure you can link it to DHCP with the limited info captured in the bug. You later say that you don't see any traffic from Windows VMI at all. Have we explored what Windows VMI does when it works in terms of DHCP? How many discovery frames does it send and how frequently? I can imagine that e1000 model (used in the yaml example) takes longer time to initialize link (as we observed in the past with cirros), but I would imagine it doesn't take minutes. What if we swap e1000 to something else? (virtio? does the image have virtio drivers?) > unfortunately, we don't install tcpdump in the pods, so it's harder to debug. > I'll try to debug with a RHEL vm, when Yan will start one on the environment > I'm using. > It's not the first time lack of tcpdump in the images makes debugging more complicated. Maybe we should consider adding it, at least in dev builds. BTW later in the comments, you said that you ran tcpdump on pod interfaces. Should we maybe capture how you did it somewhere? (I assume you did it without rebuilding virt-handler image?)
@Yan, do you have an env devs can look at? is it reproduced on 0.6.3?
(In reply to Ihar Hrachyshka from comment #9) > (In reply to Fabian Deutsch from comment #3) > > This could be because downstream is not supporting SLIRP. > > > > It might be that for CNV we need to use the delegateIP option by default. > > This would mean that we need to make the default network approach > > configurable. > > Could you please explain why SLIRP is relevant here? The example file used > (vmi-windows.yaml) doesn't use slirp but bridge (with implicit delegateIp = > true). Even if it would not specify bridge explicitly, kubevirt will add a > default pod interface that is of bridge type. So, back then - without details - I actually thought (needs to be confirmed) that SLIRP is not supported in qemu-kvm-rhev which is used by the downstream builds. This would mean that any VM connected to the network using SLIRP would not have connectivity. What I missed is that windows-vmi.yaml does not use slirp.
(In reply to Nelly Credi from comment #11) > @Yan, do you have an env devs can look at? > is it reproduced on 0.6.3? Yes, It could be reproduced on ds v0.6.3. I have preserved a env for debugging on our openstack. Ping me if you need
(In reply to Yan Du from comment #13) > (In reply to Nelly Credi from comment #11) > > @Yan, do you have an env devs can look at? > > is it reproduced on 0.6.3? > > Yes, It could be reproduced on ds v0.6.3. I have preserved a env for > debugging on our openstack. Ping me if you need @Yan, thanks. I think we need an env. where we could get to the vms' vnc console, to better understand what's happening with the windows OS. Is there such an environment? Thanks!
I found another way to get the vm status. we can get screenshot of vm # oc exec -p virt-launcher-vmi-windows-9pwk6 -- virsh screenshot 1 --file /tmp/t.ppm then cp ppm file and check status, in my env. the windows not up, it's crashed, i will check another healthy win images.
hi after i change my windows image, i re-test this, windows vm up after 30mins, and i can ping it now, but i still can't use vnc to connect the vm, it always show "Waiting for display 1", when i use virsh screenshot, i get the view of vm, it show windows interface. I left my environment(comment 15)
(In reply to zhe peng from comment #17) > hi > after i change my windows image, i re-test this, > windows vm up after 30mins, and i can ping it now, but i still can't use vnc > to connect the vm, it always show "Waiting for display 1", > when i use virsh screenshot, i get the view of vm, it show windows interface. > I left my environment(comment 15) Hi, Thanks a lot for reproducing it. These are good news, that this is not a networking problem after all. I'll take a look at the vnc problem, but overall, I'd suggest closing this bug. (perhaps we'll need another one for the vnc issue) Thanks, Vladik
Zhe, please file an independent bug about VNC. I'd be closing this bug per Vladik recommendation - it seems like very slow storage, not a networking error.
Dan, thanks, i already file one bug about vnc connection: https://bugzilla.redhat.com/show_bug.cgi?id=1619218