Review Request 13490: [DOC] add document - custom cpu model for kvm guest.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13490/ --- Review request for cloudstack and Wei Zhou. Repository: cloudstack-git Description --- add document for custom cpu model for kvm guest. Diffs - docs/en-US/hypervisor-host-install-agent.xml 41b6719 Diff: https://reviews.apache.org/r/13490/diff/ Testing --- Thanks, Jijun
Fwd: no Public Network exist in Advance Zone with Security Group enabled
hi all, now we try to add advance zone , shared network offering with security group enabled. but in the UI when click the next step we can not choose the public network. when vm created , cpvm , ssvm will get a public ip address from guest network. is there any design considerations? -- Thanks, Jijun
[Questions]: Basic Zone Securiy Group problem?
--physdev-in vif21.0 --physdev-is-bridged !set i-2-7-VM src DROP all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-out vif21.0 --physdev-is-bridged !set i-2-7-VM dst i-2-7-VM-eg all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in vif21.0 --physdev-is-bridged set i-2-7-VM src i-2-7-VM all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-out vif21.0 --physdev-is-bridged Chain i-3-8-VM (1 references) target prot opt source destination DROP all -- 0.0.0.0/00.0.0.0/0 Chain i-3-8-VM-eg (1 references) target prot opt source destination RETURN all -- 0.0.0.0/00.0.0.0/0 Chain i-3-8-def (2 references) target prot opt source destination RETURN udp -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in vif20.0 --physdev-is-bridged set i-3-8-VM src udp dpt:53 DROP all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in vif20.0 --physdev-is-bridged !set i-3-8-VM src DROP all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-out vif20.0 --physdev-is-bridged !set i-3-8-VM dst i-3-8-VM-eg all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in vif20.0 --physdev-is-bridged set i-3-8-VM src i-3-8-VM all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-out vif20.0 --physdev-is-bridged Chain r-4-VM (4 references) target prot opt source destination RETURN all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in vif19.0 --physdev-is-bridged RETURN all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in vif19.1 --physdev-is-bridged ACCEPT all -- 0.0.0.0/00.0.0.0/0 Chain s-6-VM (8 references) target prot opt source destination RETURN all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in vif18.2 --physdev-is-bridged RETURN all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in vif18.0 --physdev-is-bridged RETURN all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in vif18.1 --physdev-is-bridged RETURN all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in vif18.3 --physdev-is-bridged ACCEPT all -- 0.0.0.0/00.0.0.0/0 Chain v-2-VM (6 references) target prot opt source destination RETURN all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in vif17.2 --physdev-is-bridged RETURN all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in vif17.0 --physdev-is-bridged RETURN all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in vif17.1 --physdev-is-bridged ACCEPT all -- 0.0.0.0/00.0.0.0/0 *[root@xenserver-dlghbuxq ~]# ebtables -L* Bridge table: filter Bridge chain: INPUT, entries: 0, policy: ACCEPT Bridge chain: FORWARD, entries: 5, policy: ACCEPT -j DEFAULT_EBTABLES -i vif21.0 -j i-2-7-VM -i vif20.0 -j i-3-8-VM -o vif20.0 -j i-3-8-VM -o vif21.0 -j i-2-7-VM Bridge chain: OUTPUT, entries: 0, policy: ACCEPT Bridge chain: DEFAULT_EBTABLES, entries: 12, policy: ACCEPT -p IPv4 --ip-dst 255.255.255.255 --ip-proto udp --ip-dport 67 -j ACCEPT -p IPv4 --ip-dst 255.255.255.255 --ip-proto udp --ip-dport 68 -j ACCEPT -p ARP --arp-op Request -j ACCEPT -p ARP --arp-op Reply -j ACCEPT -p IPv4 -d Broadcast -j DROP -p IPv4 -d Multicast -j DROP -p IPv4 --ip-dst 255.255.255.255 -j DROP -p IPv4 --ip-dst 224.0.0.0/4 -j DROP -p IPv4 -j RETURN -p IPv6 -j DROP -p 802_1Q -j DROP -j DROP Bridge chain: i-3-8-VM, entries: 2, policy: ACCEPT -p IPv4 -i vif20.0 --ip-proto udp --ip-dport 68 -j DROP -p IPv4 -o vif20.0 --ip-proto udp --ip-dport 67 -j DROP Bridge chain: i-2-7-VM, entries: 2, policy: ACCEPT -p IPv4 -i vif21.0 --ip-proto udp --ip-dport 68 -j DROP -p IPv4 -o vif21.0 --ip-proto udp --ip-dport 67 -j DROP *[root@xenserver-dlghbuxq ~]# ipset -L* Name: i-3-8-VM Type: iphash References: 4 Header: hashsize: 1024 probes: 8 resize: 50 Members: 192.168.253.66 Name: i-2-7-VM Type: iphash References: 4 Header: hashsize: 1024 probes: 8 resize: 50 Members: 192.168.253.68 -- Thanks, Jijun
Re: [Questions]: Basic Zone Securiy Group problem?
0.0.0.0/0 On 08/30/2013 02:02 PM, Jayapal Reddy Uradi wrote: Hi, The rules are looking as expected. The ingress traffic to vm should block. Can you run 'iptables -L -nv' and see which rules are accepting the ingress traffic. Thanks, Jayapal On 30-Aug-2013, at 7:41 AM, Jijun wrote: i clone branch 4.2 code, package and do a fresh installation. hypervisor : xenserver 6.2 change openvswitch to bridge. add basic zone ,security group enabeld. create a new vm , default security group the previous version document said the ingress will be blocked by default. but in my test, the network in and out are all allowed. so strange. is it a bug ? iptable rule in hypervisor : [root@xenserver-dlghbuxq ~]# iptables -nL Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination BRIDGE-FIREWALL all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-is-bridged ACCEPT all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-out eth1 --physdev-is-bridged ACCEPT all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-out eth0 --physdev-is-bridged DROP all -- 0.0.0.0/00.0.0.0/0 Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain BRIDGE-DEFAULT-FIREWALL (1 references) target prot opt source destination ACCEPT all -- 0.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED ACCEPT udp -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-is-bridged udp spt:68 dpt:67 ACCEPT udp -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-is-bridged udp spt:67 dpt:68 Chain BRIDGE-FIREWALL (1 references) target prot opt source destination BRIDGE-DEFAULT-FIREWALL all -- 0.0.0.0/0 0.0.0.0/0 i-2-7-def all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in vif21.0 --physdev-is-bridged i-3-8-def all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in vif20.0 --physdev-is-bridged r-4-VM all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in vif19.0 --physdev-is-bridged r-4-VM all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in vif19.1 --physdev-is-bridged s-6-VM all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in vif18.2 --physdev-is-bridged s-6-VM all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in vif18.0 --physdev-is-bridged s-6-VM all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in vif18.1 --physdev-is-bridged s-6-VM all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in vif18.3 --physdev-is-bridged v-2-VM all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in vif17.2 --physdev-is-bridged v-2-VM all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in vif17.0 --physdev-is-bridged v-2-VM all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in vif17.1 --physdev-is-bridged v-2-VM all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-out vif17.1 --physdev-is-bridged v-2-VM all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-out vif17.0 --physdev-is-bridged v-2-VM all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-out vif17.2 --physdev-is-bridged s-6-VM all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-out vif18.3 --physdev-is-bridged s-6-VM all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-out vif18.1 --physdev-is-bridged s-6-VM all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-out vif18.0 --physdev-is-bridged s-6-VM all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-out vif18.2 --physdev-is-bridged r-4-VM all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-out vif19.1 --physdev-is-bridged r-4-VM all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-out vif19.0 --physdev-is-bridged i-3-8-def all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-out vif20.0 --physdev-is-bridged i-2-7-def all -- 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-out vif21.0 --physdev-is-bridged Chain L (0 references) target prot opt source destination Chain RH-Firewall-1-INPUT (0 references) target prot opt source destination Chain i-2-7-VM (1 references) target prot opt source destination DROP all -- 0.0.0.0/00.0.0.0/0 Chain i-2-7-VM-eg (1 references) target prot opt source destination RETURN all -- 0.0.0.0/00.0.0.0/0 Chain i-
Re: Security Groups
hi , i encounter the same problem, as i know, XenServer 6.2 need not the CSP. but the ingress not be blocked by default. i can ping all the Vms in that security group. i don't know why? Thanks. On 09/13/2013 02:02 AM, Michael Phillips wrote: So that is definitely going to be the issue. I missed that in the 8.2.7 section of the install guide. From: sangeetha.hariha...@citrix.com To: dev@cloudstack.apache.org Subject: RE: Security Groups Date: Thu, 12 Sep 2013 17:19:16 + If you are using Xenserver hosts , can you make sure you have the CSP packages installed? -Thanks Sangeetha -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Thursday, September 12, 2013 9:33 AM To: dev@cloudstack.apache.org Subject: Security Groups I posed this question in the user list, but I figured I would throw it out here as well...So If I have created a zone with the "DefaultSharedNetworkOfferingWithSGService" network offering, then created a VM using the default security group, which has 0 ingress rules, I should NOT be able to do things like PING that VM correct? The answer to the above question was answered "correct"...My next question is, in that case what are some things I could look at to see why it's not behaving as expected. -- Thanks, Jijun
Re: Security Groups
that resolve my problem ,thanks a lot! On 09/13/2013 06:13 PM, Lynch, Gerard wrote: By default XenServer (6.x) disables iptable/arptable checking over bridges in /etc/sysctl.conf - you'll need to ensure those are enabled. net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-arptables = 1 On 13/09/2013 04:55, "Jijun" wrote: hi , i encounter the same problem, as i know, XenServer 6.2 need not the CSP. but the ingress not be blocked by default. i can ping all the Vms in that security group. i don't know why? Thanks. On 09/13/2013 02:02 AM, Michael Phillips wrote: So that is definitely going to be the issue. I missed that in the 8.2.7 section of the install guide. From: sangeetha.hariha...@citrix.com To: dev@cloudstack.apache.org Subject: RE: Security Groups Date: Thu, 12 Sep 2013 17:19:16 + If you are using Xenserver hosts , can you make sure you have the CSP packages installed? -Thanks Sangeetha -Original Message- From: Michael Phillips [mailto:mphilli7...@hotmail.com] Sent: Thursday, September 12, 2013 9:33 AM To: dev@cloudstack.apache.org Subject: Security Groups I posed this question in the user list, but I figured I would throw it out here as well...So If I have created a zone with the "DefaultSharedNetworkOfferingWithSGService" network offering, then created a VM using the default security group, which has 0 ingress rules, I should NOT be able to do things like PING that VM correct? The answer to the above question was answered "correct"...My next question is, in that case what are some things I could look at to see why it's not behaving as expected. -- Thanks, Jijun Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of British Sky Broadcasting Group plc and Sky International AG and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. -- Thanks, Jijun
CS4.2 KVM VM Snapshot not implement yet?
hi all, i install CS4.2 from the url : http://cloudstack.apt-get.eu/ubuntu/ , then create Basic Zone with KVM host added,then create some vms ,everything work fine. create vm snapshot for one stopped vm, the snapshot progress is always with state "Creating". Management Server log : 2013-09-29 09:35:23,600 WARN [agent.manager.AgentManagerImpl] (Job-Executor-2:job-84 = [ 538f1c49-f0fc-425c-a1c8-f2216cfad797 ]) Unsupported Command: Unsupported command issued:com.cloud.agent.api.CreateVMSnapshotCommand. Are you sure you got the right type of server? seem that it is a bug? https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Snapshots -- Thanks, Jijun
Re: [Ask] Resize Primary Storage
On 06/26/2013 12:56 PM, Denni Sembiring wrote: Yes Sir, I use NFS Server 4. when I use this command $ virsh pool-list on my hypervisor, its shown like this [root@hypervs ~]# virsh pool-list Name State Autostart - 0f1c578f-c006-317c-b622-15d77214c1b7 active no 422155c4-15f5-4354-9ace-540b4c94ebb6 active no 6260fa35-58f0-3ba3-9337-c05fac113f57 active no 67779d92-1966-3842-aed1-54e565f372da active no fd8f79e7-46e7-3337-ad57-bd09356b4f7a active no I didn't understand about it Sir. What should I do? on the list shows that the status active no. Do i have to activate it first? virsh pool-list show the pool list the libvirt in your hypervisor . just like the result header said: [root@hypervs ~]# virsh pool-list Name State Autostart - 0f1c578f-c006-317c-b622-15d77214c1b7 active no it means: the Name(uuid) is 0f1c578f-c006-317c-b622-15d77214c1b7 , the State is active, Autostart is no. you can get the detail of the pool 0f1c578f-c006-317c-b622-15d77214c1b7 by this : [root@hypervs ~]# virsh pool-info 0f1c578f-c006-317c-b622-15d77214c1b7 Name: 0f1c578f-c006-317c-b622-15d77214c1b7 UUID: 0f1c578f-c006-317c-b622-15d77214c1b7 State: running Persistent: yes Autostart: no Capacity: 1.72 TB Allocation: 150.58 GB Available: 1.57 TB Thanks, Jijun If yes, how do I enable it? Thanks, Regards, Denni sembiring 2013/6/25 Wido den Hollander Hi, On 06/25/2013 06:41 AM, Denni Sembiring wrote: I had to install Cloudstack 4.02. I use 5 hosts, 1 as management server, and the other into the hypervisor (KVM). when all has gone well, I went to the UI and see my primary storage show only 98 Gb , while the entire capacity of hypervisor should be 2 Tb . How can I change the size of my primary storage? what should i do so my primary storage size according to the size of my hypervisor? The management server gets the information from libvirt on the hypervisor. Is this NFS? What does this show on the hypervisor: $ virsh pool-info Wher you can list the storage pools in libvirt with: $ virsh pool-list Wido Best regards, Denni Sembiring Del Polytechnic of Informatics
Re: [Ask] Resize Primary Storage
On 06/26/2013 02:10 PM, Denni Sembiring wrote: Thank you Jijun. I've tried it, and I want to ask, how do we allocate the whole of the hypervisor capacity as a primary storage? I mean in the UI we will see the capacity of primary storage show 1.72 TB. will it possible? yes , in my UI (CS 3.0.x) Disk Total shows 1.72TB equals to result of virsh pool-info. thanks, Denni Sembiring 2013/6/25 Jijun On 06/26/2013 12:56 PM, Denni Sembiring wrote: Yes Sir, I use NFS Server 4. when I use this command $ virsh pool-list on my hypervisor, its shown like this [root@hypervs ~]# virsh pool-list Name State Autostart --**--- 0f1c578f-c006-317c-b622-**15d77214c1b7 active no 422155c4-15f5-4354-9ace-**540b4c94ebb6 active no 6260fa35-58f0-3ba3-9337-**c05fac113f57 active no 67779d92-1966-3842-aed1-**54e565f372da active no fd8f79e7-46e7-3337-ad57-**bd09356b4f7a active no I didn't understand about it Sir. What should I do? on the list shows that the status active no. Do i have to activate it first? virsh pool-list show the pool list the libvirt in your hypervisor . just like the result header said: [root@hypervs ~]# virsh pool-list Name State Autostart --**--- 0f1c578f-c006-317c-b622-**15d77214c1b7 active no it means: the Name(uuid) is 0f1c578f-c006-317c-b622-**15d77214c1b7 , the State is active, Autostart is no. you can get the detail of the pool 0f1c578f-c006-317c-b622-**15d77214c1b7 by this : [root@hypervs ~]# virsh pool-info 0f1c578f-c006-317c-b622-**15d77214c1b7 Name: 0f1c578f-c006-317c-b622-**15d77214c1b7 UUID: 0f1c578f-c006-317c-b622-**15d77214c1b7 State: running Persistent: yes Autostart: no Capacity: 1.72 TB Allocation: 150.58 GB Available: 1.57 TB Thanks, Jijun If yes, how do I enable it? Thanks, Regards, Denni sembiring 2013/6/25 Wido den Hollander Hi, On 06/25/2013 06:41 AM, Denni Sembiring wrote: I had to install Cloudstack 4.02. I use 5 hosts, 1 as management server, and the other into the hypervisor (KVM). when all has gone well, I went to the UI and see my primary storage show only 98 Gb , while the entire capacity of hypervisor should be 2 Tb . How can I change the size of my primary storage? what should i do so my primary storage size according to the size of my hypervisor? The management server gets the information from libvirt on the hypervisor. Is this NFS? What does this show on the hypervisor: $ virsh pool-info Wher you can list the storage pools in libvirt with: $ virsh pool-list Wido Best regards, Denni Sembiring Del Polytechnic of Informatics
Bug : Create Vmware Advance Zone , Public Network with vlan 509 specified, but portgroup created is cloud.public.untagged.0.1-vSwitch0 not cloud.public.509.0.1-vSwitch0
Hi all, In lastest CS 4.2 code, I create advance zone with hypervisor vmware esxi, create public Network with vlan id 509 specified and label vSwitch0, when cs create systemvm(cpvm,ssvm), a new portgroup with name cloud.public.untagged.0.1-vSwitch0 was created, not a portgroup cloud.public.509.0.1-vSwitch0 as expected. in database table nics, the field broadcast_uri for new systemvm is vlan:509 , and should be vlan://509 I debug the code , and found the problem in Networks.java api/src/com/cloud/network/Networks.java line 222 188 public enum IsolationType { .. 212 public URI toUri(T value) { 213 try { 214 // assert(this!=Vlan || 215 // value.getClass().isAssignableFrom(Integer.class)) : 216 // do we need to check that value does not contain a scheme 217 // part? 218 // "Why are you putting non integer into vlan url"; 219 if (value.toString().contains(":")) 220 return new URI(value.toString()); 221 else 222 return new URI(scheme, value.toString(), null); 223 } catch (URISyntaxException e) { 224 throw new CloudRuntimeException( 225 "Unable to convert to isolation type URI: " + value); 226 } 227 } line 222 should be changed to : return new URI(scheme,value.toString(),null,null); or return new URI(scheme + "://" + value.toString()); same bug in the same file line 100, enum BroadcastDomainType . anyone can test and fix it? diff --git a/api/src/com/cloud/network/Networks.java b/api/src/com/cloud/network/Networks.java index c76c3d4..672b69b 100755 --- a/api/src/com/cloud/network/Networks.java +++ b/api/src/com/cloud/network/Networks.java @@ -97,7 +97,7 @@ public class Networks { if (value.toString().contains(":")) return new URI(value.toString()); else -return new URI(scheme, value.toString(), null); +return new URI(scheme, value.toString(), null, null); } catch (URISyntaxException e) { throw new CloudRuntimeException( "Unable to convert to broadcast URI: " + value); @@ -219,7 +219,7 @@ public class Networks { if (value.toString().contains(":")) return new URI(value.toString()); else -return new URI(scheme, value.toString(), null); +return new URI(scheme, value.toString(), null, null); } catch (URISyntaxException e) { throw new CloudRuntimeException( "Unable to convert to isolation type URI: " + value); -- Thanks, Jijun
Review Request 13004: Bug:advance zone, create public Network with vlan id specified, but the portgroup is cloud.public.untagged.0.1-vSwitch0 not cloud.public.[vlanid].0.1-vSwitch0
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13004/ --- Review request for cloudstack, edison su and Wei Zhou. Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-3883 Repository: cloudstack-git Description --- In lastest CS 4.2 code, I create advance zone with hypervisor vmware esxi, create public Network with vlan id 509 specified and label vSwitch0, when cs create systemvm(cpvm,ssvm), a new portgroup with name cloud.public.untagged.0.1-vSwitch0 was created, not a portgroup cloud.public.509.0.1-vSwitch0 as expected. in database table nics, the field broadcast_uri for new systemvm is vlan:509 , and should be vlan://509 debug the code and found it is a syntax error in Networks.java for new instance java.net.URI. Diffs - api/src/com/cloud/network/Networks.java c76c3d4 Diff: https://reviews.apache.org/r/13004/diff/ Testing --- recreate the system vm or create a new advance zone , public network with vlan Thanks, Jijun
Re: Review Request 13004: Bug:advance zone, create public Network with vlan id specified, but the portgroup is cloud.public.untagged.0.1-vSwitch0 not cloud.public.[vlanid].0.1-vSwitch0
> On July 29, 2013, 8:30 a.m., daan Hoogland wrote: > > Jijun, please make sure your adjusted call to URI() only gets called when > > BroadcastDomainType is Vlan, Storage or Mido and not when it is for > > instance Lswitch. when scheme is vlan, some code will invoke URI.getHost(), but it will return null, and should be vlan id. in fact , it is the issue of IsolationType. but i find BroadcastDomainType has the same logic,so i change it too. maybe i should check the scheme in function toURI(). - Jijun --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13004/#review24098 --- On July 28, 2013, 11:49 a.m., Jijun wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/13004/ > --- > > (Updated July 28, 2013, 11:49 a.m.) > > > Review request for cloudstack, edison su and Wei Zhou. > > > Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-3883 > > > Repository: cloudstack-git > > > Description > --- > > In lastest CS 4.2 code, I create advance zone with hypervisor vmware esxi, > create public Network with vlan id 509 specified and label vSwitch0, when cs > create systemvm(cpvm,ssvm), > a new portgroup with name cloud.public.untagged.0.1-vSwitch0 was created, > not a portgroup cloud.public.509.0.1-vSwitch0 as expected. > in database table nics, the field broadcast_uri for new systemvm is vlan:509 > , and should be vlan://509 > debug the code and found it is a syntax error in Networks.java for new > instance java.net.URI. > > > Diffs > - > > api/src/com/cloud/network/Networks.java c76c3d4 > > Diff: https://reviews.apache.org/r/13004/diff/ > > > Testing > --- > > recreate the system vm or create a new advance zone , public network with vlan > > > Thanks, > > Jijun > >
Re: Review Request 13004: Bug:advance zone, create public Network with vlan id specified, but the portgroup is cloud.public.untagged.0.1-vSwitch0 not cloud.public.[vlanid].0.1-vSwitch0
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13004/ --- (Updated July 29, 2013, 11:07 a.m.) Review request for cloudstack, daan Hoogland, edison su, and Wei Zhou. Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-3883 Repository: cloudstack-git Description --- In lastest CS 4.2 code, I create advance zone with hypervisor vmware esxi, create public Network with vlan id 509 specified and label vSwitch0, when cs create systemvm(cpvm,ssvm), a new portgroup with name cloud.public.untagged.0.1-vSwitch0 was created, not a portgroup cloud.public.509.0.1-vSwitch0 as expected. in database table nics, the field broadcast_uri for new systemvm is vlan:509 , and should be vlan://509 debug the code and found it is a syntax error in Networks.java for new instance java.net.URI. Diffs - api/src/com/cloud/network/Networks.java c76c3d4 Diff: https://reviews.apache.org/r/13004/diff/ Testing --- recreate the system vm or create a new advance zone , public network with vlan Thanks, Jijun
Re: Review Request 13004: Bug:advance zone, create public Network with vlan id specified, but the portgroup is cloud.public.untagged.0.1-vSwitch0 not cloud.public.[vlanid].0.1-vSwitch0
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13004/ --- (Updated July 30, 2013, 12:58 a.m.) Review request for cloudstack, daan Hoogland, edison su, and Wei Zhou. Changes --- add scheme check for vlan Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-3883 Repository: cloudstack-git Description --- In lastest CS 4.2 code, I create advance zone with hypervisor vmware esxi, create public Network with vlan id 509 specified and label vSwitch0, when cs create systemvm(cpvm,ssvm), a new portgroup with name cloud.public.untagged.0.1-vSwitch0 was created, not a portgroup cloud.public.509.0.1-vSwitch0 as expected. in database table nics, the field broadcast_uri for new systemvm is vlan:509 , and should be vlan://509 debug the code and found it is a syntax error in Networks.java for new instance java.net.URI. Diffs (updated) - api/src/com/cloud/network/Networks.java c76c3d4 Diff: https://reviews.apache.org/r/13004/diff/ Testing --- recreate the system vm or create a new advance zone , public network with vlan Thanks, Jijun
Re: Network Problem
Hi , Basic Network will setup the security group, and it will deny all the inbound traffic and allow outbound traffic. you should manually add some ingress rules. offical document: http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.0.2/html/Installation_Guide/security-groups.html On 07/30/2013 01:34 AM, Thomas Schneider wrote: Hello, I have setup cloudstack and it work fine, I can launch VM etc... But the problem is I can only SSH to the VM from the host on which she is running. When I am in the vm I can ping exernal network and download package to setup lamp for example. I'm in basic network mode My config is: mgmt srv: 10.10.10.20 host1: 10.10.10.30 host2: 10.10.10.31 nfs for storage 10.10.10.100 pod pool 10.10.10.110 - 150 guest pool 10.10.10.200 -250 and my network config on the host in /etc/init.d/networking/interface is: --- auto p49p1 iface p49p1 inet manual auto cloudbr0 iface cloudbr0 inet static bridge_ports p49p1 address 10.10.10.31 netmask 255.255.255.0 network 10.10.10.0 broadcast 10.10.10.255 gateway 10.10.10.254 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 10.1.1.2 --- I also with to use OpenVSwitch but I didn't found a lot of documentation for configuring in basic nework mode on ubuntu. Tkanks for your Help. Best Regards, -- Thanks, Jijun
Re: Review Request 13004: Bug:advance zone, create public Network with vlan id specified, but the portgroup is cloud.public.untagged.0.1-vSwitch0 not cloud.public.[vlanid].0.1-vSwitch0
> On July 30, 2013, 11:13 p.m., edison su wrote: > > I looked at latest 4.2 code, toURI() only contains one line code: return > > new URI(scheme + "://" + value.toString());, thus can't apply your patch. > > Could you tell me which branch are you using? The master? hi edison, yes,it is in the master,not the branch 4.2. - Jijun --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13004/#review24296 --- On July 30, 2013, 12:58 a.m., Jijun wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/13004/ > --- > > (Updated July 30, 2013, 12:58 a.m.) > > > Review request for cloudstack, daan Hoogland, edison su, and Wei Zhou. > > > Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-3883 > > > Repository: cloudstack-git > > > Description > --- > > In lastest CS 4.2 code, I create advance zone with hypervisor vmware esxi, > create public Network with vlan id 509 specified and label vSwitch0, when cs > create systemvm(cpvm,ssvm), > a new portgroup with name cloud.public.untagged.0.1-vSwitch0 was created, > not a portgroup cloud.public.509.0.1-vSwitch0 as expected. > in database table nics, the field broadcast_uri for new systemvm is vlan:509 > , and should be vlan://509 > debug the code and found it is a syntax error in Networks.java for new > instance java.net.URI. > > > Diffs > - > > api/src/com/cloud/network/Networks.java c76c3d4 > > Diff: https://reviews.apache.org/r/13004/diff/ > > > Testing > --- > > recreate the system vm or create a new advance zone , public network with vlan > > > Thanks, > > Jijun > >
integrate VMware vShield as SecurityGroup in Cloudstack?
hi, is there any plan to integrate VMware vShield as Security Group in Cloudstack? or any suggestion to develop this feature to work with Cloudstack? any suggestion will be appreciated!thanks. -- Thanks, Jijun
Review Request 15748: vmware os type error for redhat 6.x
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15748/ --- Review request for cloudstack and daan Hoogland. Bugs: CLOUDSTACK-5225 https://issues.apache.org/jira/browse/CLOUDSTACK-5225 Repository: cloudstack-git Description --- upload a redhat 6.x iso or template , start a vm using it. check the os type in vsphere client, the vm os type is other 64 linux. the vmware-tools can not be installed due to the issue. Diffs - vmware-base/src/com/cloud/hypervisor/vmware/util/VmwareGuestOsMapper.java b8c3e8d Diff: https://reviews.apache.org/r/15748/diff/ Testing --- Thanks, Jijun
Review Request 12360: custom cpu model for kvm guest.the default model 'QEMU Virtual CPU version xxx' affect the activation of Windows OS and low performance.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12360/ --- Review request for cloudstack, edison su, soren, and Wei Zhou. Summary (updated) - custom cpu model for kvm guest.the default model 'QEMU Virtual CPU version xxx' affect the activation of Windows OS and low performance. Repository: cloudstack-git Description (updated) --- Add cpu model for kvm guest.Now all the kvm guest's cpu model is 'QEMU Virtual CPU version xxx'. This will affect the activation of Windows OS and low performance. I add three mode for user to indicate the guest cpu model. some ideas come from openstack and libvirt. user can uncomment guest.cpu.mode and guest.cpu.model in agent.properties to enable this feature.it is disabled by default. some details as follows: custom - user custom the CPU model which specified by guest.cpu.model. host-model - identify the named CPU model which most closely matches the host, and then request additional CPU flags to complete the match. This should give close to maximum functionality/performance, which maintaining good reliability/compatibility if the guest is migrated to another host with slightly different host CPUs. host-passthrough - tell KVM to passthrough the host CPU with no modifications. The difference to host-model, instead of just matching feature flags, every last detail of the host CPU is matched. This gives absolutely best performance,and can be important to some apps which check low level CPU details, but it comes at a cost wrt migration. The guest can only be migrated to an exactly matching host CPU. Diffs (updated) - agent/conf/agent.properties 60030ae plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java 914017c plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtVMDef.java 5120870 plugins/hypervisors/kvm/test/com/cloud/hypervisor/kvm/resource/LibvirtVMDefTest.java 2c0ff8d Diff: https://reviews.apache.org/r/12360/diff/ Testing (updated) --- 1.set guest.cpu.mode=custom,guest.cpu.model=Nehalem in agent.properties,you can get more guest.cpu.model by execute virsh capabilities .create a new vm instance or reboot your vm instance,the guest's cpu model will change as guest.cpu.model specified. 2.set guest.cpu.mode=host-model,create a new vm instance or reboot your vm instance the guest's cpu model will be a closely cpu model as your hypervisor. 3.set guest.cpu.mode=host-passthrough,create a new vm instance or reboot your vm instance,the guest's cpu model should be the cpu model as your hypervisor. Thanks, Jijun Liu
Re: Review Request 12360: custom cpu model for kvm guest.the default model 'QEMU Virtual CPU version xxx' affect the activation of Windows OS and low performance.
> On July 10, 2013, 6:50 a.m., Wei Zhou wrote: > > plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtVMDef.java, > > line 956 > > <https://reviews.apache.org/r/12360/diff/2/?file=319577#file319577line956> > > > > It is mentioned in http://libvirt.org/formatdomain.html that "Since > > 0.9.10, an optional mode attribute may be used to make it easier to > > configure a guest CPU to be as close to host CPU as possible". Hence, I > > think it is better to compare _libvirtVersion here. This feature supports > > from libvirt 0.9.10. i will do the version check in LibvirtComputingResource.java. - Jijun --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12360/#review22949 ------- On July 10, 2013, 3 a.m., Jijun Liu wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/12360/ > --- > > (Updated July 10, 2013, 3 a.m.) > > > Review request for cloudstack, edison su, soren, and Wei Zhou. > > > Repository: cloudstack-git > > > Description > --- > > Add cpu model for kvm guest.Now all the kvm guest's cpu model is 'QEMU > Virtual CPU version xxx'. This will affect the activation of Windows OS and > low performance. I add three mode for user to indicate the guest cpu model. > some ideas come from openstack and libvirt. > user can uncomment guest.cpu.mode and guest.cpu.model in agent.properties to > enable this feature.it is disabled by default. > some details as follows: > custom - user custom the CPU model which specified by guest.cpu.model. > host-model - identify the named CPU model which most closely matches the > host, and then request additional CPU flags to complete the match. This > should give close to maximum functionality/performance, which maintaining > good reliability/compatibility if the guest is migrated to another host with > slightly different host CPUs. > host-passthrough - tell KVM to passthrough the host CPU with no > modifications. The difference to host-model, instead of just matching feature > flags, every last detail of the host CPU is matched. This gives absolutely > best performance,and can be important to some apps which check low level CPU > details, but it comes at a cost wrt migration. The guest can only be migrated > to an exactly matching host CPU. > > > Diffs > - > > agent/conf/agent.properties 60030ae > > plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java > 914017c > > plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtVMDef.java > 5120870 > > plugins/hypervisors/kvm/test/com/cloud/hypervisor/kvm/resource/LibvirtVMDefTest.java > 2c0ff8d > > Diff: https://reviews.apache.org/r/12360/diff/ > > > Testing > --- > > 1.set guest.cpu.mode=custom,guest.cpu.model=Nehalem in agent.properties,you > can get more guest.cpu.model by execute virsh capabilities .create a new vm > instance or reboot your vm instance,the guest's cpu model will change as > guest.cpu.model specified. > 2.set guest.cpu.mode=host-model,create a new vm instance or reboot your vm > instance the guest's cpu model will be a closely cpu model as your hypervisor. > 3.set guest.cpu.mode=host-passthrough,create a new vm instance or reboot your > vm instance,the guest's cpu model should be the cpu model as your hypervisor. > > > Thanks, > > Jijun Liu > >
Re: Review Request 12360: custom cpu model for kvm guest.the default model 'QEMU Virtual CPU version xxx' affect the activation of Windows OS and low performance.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12360/ --- (Updated July 14, 2013, 3:38 a.m.) Review request for cloudstack, edison su, soren, and Wei Zhou. Changes --- add libvirt version check Repository: cloudstack-git Description --- Add cpu model for kvm guest.Now all the kvm guest's cpu model is 'QEMU Virtual CPU version xxx'. This will affect the activation of Windows OS and low performance. I add three mode for user to indicate the guest cpu model. some ideas come from openstack and libvirt. user can uncomment guest.cpu.mode and guest.cpu.model in agent.properties to enable this feature.it is disabled by default. some details as follows: custom - user custom the CPU model which specified by guest.cpu.model. host-model - identify the named CPU model which most closely matches the host, and then request additional CPU flags to complete the match. This should give close to maximum functionality/performance, which maintaining good reliability/compatibility if the guest is migrated to another host with slightly different host CPUs. host-passthrough - tell KVM to passthrough the host CPU with no modifications. The difference to host-model, instead of just matching feature flags, every last detail of the host CPU is matched. This gives absolutely best performance,and can be important to some apps which check low level CPU details, but it comes at a cost wrt migration. The guest can only be migrated to an exactly matching host CPU. Diffs (updated) - agent/conf/agent.properties 60030ae plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java 24f9ee0 plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtVMDef.java 5120870 plugins/hypervisors/kvm/test/com/cloud/hypervisor/kvm/resource/LibvirtVMDefTest.java 2c0ff8d Diff: https://reviews.apache.org/r/12360/diff/ Testing --- 1.set guest.cpu.mode=custom,guest.cpu.model=Nehalem in agent.properties,you can get more guest.cpu.model by execute virsh capabilities .create a new vm instance or reboot your vm instance,the guest's cpu model will change as guest.cpu.model specified. 2.set guest.cpu.mode=host-model,create a new vm instance or reboot your vm instance the guest's cpu model will be a closely cpu model as your hypervisor. 3.set guest.cpu.mode=host-passthrough,create a new vm instance or reboot your vm instance,the guest's cpu model should be the cpu model as your hypervisor. Thanks, Jijun Liu