Hi
After upgrade and restarting system-VM's
all VR started with some bad network configuration, egress rules stopped
work.
also some staticNAT rules,
there is " ip addr show " from one of VR's
root@r-256-VM:~# ip addr show
1: lo: mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:
No idea, but have you verified that the vm is running the new system
vm template? What happens if you destroy the router and let it
recreate?
On Sun, Apr 20, 2014 at 6:20 PM, Serg Senko wrote:
> Hi
>
> After upgrade and restarting system-VM's
> all VR started with some bad network configuration,
No, it has nothing to do with ssh or libvirt daemon. It's the literal
unix socket that is created for virtio-serial communication when the
qemu process starts. The question is why the system is refusing access
to the socket. I assume this is being attempted as root.
On Sat, Apr 19, 2014 at 9:58 AM
You may want to look in the qemu log of the vm to see if there's
something deeper going on, perhaps the qemu process is not fully
starting due to some other issue. /var/log/libvirt/qemu/v-1-VM.log, or
something like that.
On Sun, Apr 20, 2014 at 11:22 PM, Marcus wrote:
> No, it has nothing to do
Type brctl show
And check your public interface of your router is plugged into cloudbr0 or
cloudbr1..If its plugged to cloubr0 and then need to detach from cloudbr0 and
attach that interface to cloudbr1 and need to apply the all the iptables rules
. Take the backup of iptables rules with ipt
Hi,
Yes sure,
root@r-256-VM:~# cat /etc/cloudstack-release
Cloudstack Release 4.3.0 (64-bit) Wed Jan 15 00:27:19 UTC 2014
Also I tried to destroy the VR and re-create, VR up with same problem.
The "cloudstack-sysvmadm" script haven't receive success answer from VR's.
I have a finish rolling
Sorry, actually I see the 'connection refused' is just your own test
after the fact. By that time the vm may be shut down, so connection
refused would make sense.
What happens if you do this:
'virsh dumpxml v-1-VM > /tmp/v-1-VM.xml' while it is running
stop the cloudstack agent
'virsh destroy v-1
Hi,
I am using CS 4.3 with esxi & vCenter 5.5, while creating system vms its
giving below error,
with reference to this bug fix
https://issues.apache.org/jira/browse/CLOUDSTACK-4875. I though it should
be in CS 4.3
2014-04-21 11:09:25,158 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-82:ctx-9d
HI Suresh,
Thanks for you answer, but isn't realistic work around in my case, I have
more than ~150 VR's, also I'm already finished rolling back to 4.1.1.
Do you have some patch or link to updated systemvm template ( if that the
ssvm issue ) ?
P.S.
The same issue, will happened with upgrade to 4.
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20516/
---
Review request for cloudstack and Jayapal Reddy.
Bugs: CLOUDSTACK-6463
http
10 matches
Mail list logo