Page History

BareMetal-TestCaseswin.xls

Requirements
. CS Management server
. CS Baremetal hosts have IPMI over LAN enabled
. CS baremetal agent providing external DHCP, PXE server
. NFS server contains linux-based boot image
. CIFS/Samba server contains windows-based boot image

Testcase
ID

Test Description

Steps

Expected Results

Priority

Type

Automatable

Zone Configuration

1

baremetal network offering

Create network offering shared, no vlan specify, dhcp, userdata, security group, baremetalPxeService

P1

functional

2

Basic Zone with BareMetal Hypervisor

No SSVM ,CPVM will be launched.
There should be no need for configuring Primary/Secondary storage.
There should be no need for configuring Pod System ip range.

P1

functional

Adding Baremetal Host

3

Add Baremetal Host providing valid values for the following:
1.IPMI Ipaddress
2.IPMI account
3.IPMI password
4.Host IP Address
5.Host Mac Address
6.Host tag

Add Baremetal Host providing via API addBaremetalHost providing valid values for the following:
1.IPMI Ipaddress
2.IPMI account
3.IPMI password
4.Host IP Address
5.Host Mac Address
6.Host tag

Host addition should succeed.

P1

functional

4

Add Baremetal Host without Host tags

Host addition should fail

P2

negative

5

Add Baremetal Host without providing a host ipaddress

Host addition should fail

P1 P2

negative

6

Add Baremetal Host without providing a Mac Address

Host addition should fail

P1 P2

negative

7

Add Baremetal Host without providing IPMI Ipaddress, account and password.

Host addition should fail

P1 P2

negative

8

Add Baremetal Host by specifying a invalid values for IPMI Ip, account and password.

Host addition should fail.

P2

negative

9

In pod, Add cluster of 2 Baremetal hosts

Add cluster of 2 Baremetal hosts

Cluster of hosts added successfully

P1

functional

Configuring and adding a TFTP TFTP DHCP PXE server

10

Configure TFTP DHCP PXE server

1. In Xencenter add Xenserver 6.0.2 host which must be on same L2 switch level as Baremetal hosts. Create Centos 6.2 VM
on Xenserver host & configure it with IP in the same subnet of guest ip range.
On this VM Install CloudStack baremetal agent and run cloud-setup-baremetal. 1. In Xencenter add Xenserver 6.0.2 host.
2. Create Centos 6.2 VM.
2. 3 VM on Xenserver host & configure it with IP in the same subnet of subnet of guest ip range.
3. Install On VM Install CloudStack baremetal agent and run cloud-setup-baremetal.

TFTP server should be started successfully.

P1

functional

11

Add a TFTP server to the zone using addBaremetalPxeKickStartServer()

1. Add a TFTP server to the zone using API addBaremetalPxeKickStartServer()

TFTP server should get added successfully to the Zone.

P1

functional

12

Add a TFTP server to the zone using addBaremetalPxeKickStartServer() when the TFTP server is not running.

1. Add a TFTP server to the zone using addBaremetalPxeKickStartServer() when the TFTP server is not running.

Should the addition of TPFT server fail ?

P1 P2

negative

Configuring External DHCP Configuring DHCP server

13

Deploy an external Configure DHCP server

Configure VM as and configure it to service all the hosts in the pod ip range. Deploy an external DHCP server and configure it to service all the hosts in the pod ip range.

P1

14

Configure DHCP server to use the TFTP server.

P1

functional

Kickstart Installation. Registering templates.

15

Register a template by passing valid values for displaytext,format,hypervisor="Baremetal", ostypeid,url="Kickstart_file_location;template_repo_on_nfs_path",zoneid .

Template registration should succeed.

P1

16

Register a template by passing url with invalid format like only Kickstart_file_location /only template_repo_on_nfs_path /using a different separator instead of ";" like Kickstart_file_location.template_repo_on_nfs_path

Template registration should fail.

P1

17

provide invalid values for Kickstart_file_location

Register a template by passing invalid values for Kickstart_file_location

Template registration should fail.

P1

18

provide invalid values for template_repo_on_nfs_path

Register a template by passing invalid values for template_repo_on_nfs_path

Template registration should fail.

P1

19

List all the templates for Baremetal hypervisors.

1. Register few "Baremetal" templates.
2. List all the templates for Baremetal hypervisors.

All the templates for Baremetal should be listed.

P1

20

Deletion of templates.

1. Register few "Baremetal" templates.
2. Delete some of the "Baremetal" templates.
3. List all the templates for Baremetal hypervisors.

Deletion of templates should succeed.
All the templates for Baremetal should be listed. This should not include the template that was deleted.

P1

Ping style Installation

21

Install Windows 2008 R2 Server on a server that is identical (CPU, memory, disk, resources) to the servers which will be used as baremetal hosts.
Use PING http://ping.windowsdream.com &nbsp

^{Image Removed}

; to backup & create image of the template OS onto network
Register a template by passing valid values for displaytext,format,hypervisor="Baremetal", ostypeid,url="ping_file_location;template_repo_on_nfs_path",zoneid .

1. Install Windows 2008 R2 Server on a server
2. Use PING to backup & create image of template OS
3. Register a template by passing valid values for displaytext,format,hypervisor="Baremetal", ostypeid,url="ping_file_location;template_repo_on_nfs_path",zoneid .

Template registration should succeed.

P1

22

Register a template by passing url with invalid format like only ping_file_location /only template_repo_on_nfs_path /using a different separator instead of ";" like ping_file_location.template_repo_on_nfs_path

Template registration should fail.

P1

23

provide invalid values for ping_file_location

Register a template by passing invalid values for ping_file_location

Template registration should fail.

P1

Deploying VM

24

Deploy a VM using a SO with host tag of a Baremetal host using a baremetal template.

Deploy a VM using a SO with host tag of a Baremetal host using a baremetal template.
Steps involved when deploying VM:
1. Program the TFTP server . Add an entry for the MAC address under /var/lib/tftpboot/pexclinux.cfg and program the details of the template to be used.
2. Contact the host using IPMI address and attempt the following:
1. boot device set to PXE
2. Power on the device.
This should result in PXE boot.
3. During the time when the device is still being PXE booted , VM status should still be presented as "Starting".
4. Management server will constantly try to reach the security agent on this host using the Ipaddress of the host. Once it is able to reach this host , then we will mark the status of the VM as being "UP" in the management server.

Vm deployment should succeed.

P1

25

Deploy a VM on a host by passing a hostname.

Vm deployment should succeed.
VM should be accessible using the hostname.

26

Deploy a VM by passing a disk offering id.

VM deployment should fail.

27

Deploy a VM using a password enabled template.

Vm deployment should succeed.
Password should be generated by cloudstack.
We should be able to access this VM using the password provided.

28

Deploy a VM using a ssh enabled template and by passing a sshkey.

Vm deployment should succeed.
Password should be generated by cloudstack.
We should be able to access this VM using the sshkeys without having to pass any password.

29

Deploy a VM using userdata

Vm deployment should succeed.
User should be able to retrieve the userdata from url ??

30

Deploy a VM when TFTP server is not yet configured in the zone.

Vm deployment should fail.

31

Deploy a VM when TFTP server is not reachable.

Vm deployment should fail.

32

Deploy a VM when DHCP server is not reachable.

Vm deployment should fail.

33

Deploy a VM when host is in "Down" state.

Vm deployment should fail.

34

Deploy a VM on a host which has an invalid ipaddress( Ipaddress does not exist in the DHCP server) assigned to it.

35

Deploy a VM on a host which has an invalid ipaddress ( Ipaddress that existis in the DHCP server but is associated with a different MAC address) assigned to it.

36

Deploy a VM on a host which has an invalid MAC address ( MAC address does not exist in the DHCP server) assigned to it.

37

Deploy a VM on a host which has an invalid MAC address ( MAC address that existis in the DHCP server but is associated with a different ip address) assigned to it.

38

Deploy a VM on a host which has an invalid ipaddress assigned to it.
Edit the ipaddress on the host to a correct ip address.
Deploy a VM on this host again.

39

Deploy a VM on a host which has an invalid MAC address assigned to it.
Edit the MAC address on the host to the correct MAC address.
Deploy a VM on this host again.

Hosts

40

Force reconnect Host()

41

UpdateHost() - Edit host tags

42

deleteHost() - > Put the host in maintenance and then delete the host

43

Put the host in maintenance mode

44

Put the host in maintenance mode and bring the host out of maintenance mode.

45

updateHostPassword() --> will not be supported ???

46

Power down host

47

Power down host and the power on the host

48

Reboot host

49

Bring down the network connectivity of the host.

50

Bring down the network connectivity of the host and then bring the network connectivity back up again.

Allocators

51

Deploy a Vm with a host tag that points to Baremetal host , when there are multiple baremetal hosts with the same host tag.

52

Deploy multiple Vm with a host tag that points to Baremetal host , when there are multiple baremetal hosts with the same host tag.

53

Deploy a Vm with a host tag that points to Baremetal host , when there is 1 Vm running in all the baremetal hosts with this host tag.

54

Deploy a Vm with a host tag when there are multiple Baremetal hosts , some with host tag - tag1 and others with host tag -tag2.

55

Deploy a Vm with a host tag that points to Baremetal host , when there is 1 Vm running in all the baremetal hosts with this host tag.
Destroy one of the VMs.
Try to deploy again. We should be able to deploy the Vm in the host from which the Vm was destroyed.

VM life Cycle:

56

Stop a VM that is running on Baremetal host.

57

Start a VM that is in "stopped" state on Baremetal host.

58

Destroy a VM.

59

Restore a VM that is in "Destroyed" state.

60

Reboot a VM that is running on Baremetal host.

61

Change the Serive Offering of a VM in "Stopped" state. Can we get the VM to start in a different host now by changing the host tags in the new service offering ?

62

Reset password for a VM that was launched with password enabled templates.

63

get password for a VM that was launched with password enabled templates.

64

Update Vm and set userdata for a VM that was deployed with no userdata.

65

Update Vm and set a different userdata for a VM that was deployed with some userdata to begin with.

66

Retrieve userdata of the user Vms.

67

Retrieve metadata of the user Vms.

68

Migrate Virtual machine() ..API should throw an error in this case.

Account

69

Delete an Account which has Vms running in SG.

Security Groups

70

Deploy a VM by passing a Security Group.

1.To the default security group, Add a TCP ingress rule for a port range (22-80) for any ipaddress (cidr1).
2.Create a Security Group SG1.
3. Add a TCP ingress rule for a port range (22-80) for any ipaddress (cidr2).
4. Deploy a VM by passing Security Group SG1.

1. VM should be deployed as part of only SG1 not default security group.
2. We should not be able to able access this VM from cidr1.
3. We should be able to able access this VM from cidr2.

71

Deploy a VM by passing a list of Security Groups.

1. Create a Security Group SG1.
2. Add a TCP ingress rule for a port range (22-80) for any ipaddress (cidr1).
3. Create a Security Group SG2.
4. Add a TCP ingress rule for a port range (22-80) for any ipaddress (cidr2).
3. Create a Security Group SG3.
4. Add a TCP ingress rule for a port range (22-80) for any ipaddress (cidr3).
4. Deploy a VM using all the 3 security groups.

1. VM should be deployed as part of all 3 SG rules.
2. VM should be accessible from cidr1,cidr2 and cidr3.

CIDR based Ingress rules

72

Deploy a VM in a Security group which has an ingress rule that allows TCP protocols for a port range for a cidr.

1.Create a Security Group SG1.
2. Add a TCP ingress rule for a port range (22-80) for any ipaddress (cidr1).
3. Deploy a VM as part of SG1.

1. VM deployment should succeed.
2. We should be able to access this VM from cidr1 using all ports from 22 -80.
3. We should NOT be able to access this VM from any other ipadress .

73

Deploy a VM in a Security group which has an ingress rule that allows ICMP protocols for a 1 type and 1 code for a cidr.

1.Create a Security Group SG1.
2. Add a ICMP ingress rule for any 1 type and 1 code for any ipaddress (cidr1).
3. Deploy a VM as part of SG1.

1. VM deployment should succeed.
2. Make sure that in iptables the correct type and code for ICMP is programmed.

73

Deploy few Vms in a Security group which has an ingress rule that allows TCP protocols for cidr1.
Add an ingress rule to allow ICMP protocols for cidr1 and cidr2.

1.Create a Security Group SG1.
2. Add a TCP ingress rule for a port range (22-80) for any ipaddress (cidr1).
3. Deploy a VM as part of SG1.
4. Add an ingress rule to allow ICMP protocols for cidr1 and cidr2.

Before Step4:
We should be able to access the VM from cidr1.
We should not be able to ping the VM from cidr1 and cidr2.
After Step4:
We should be able to access the VM from cidr1.
We should be able to ping the VM from cidr1 and cidr2.

74

Deploy few Vms in a Security group which has an ingress rule that allows TCP protocols for cidr1 and cidr2.
Delete the existing ingress rule for cidr1.

1.Create a Security Group SG1.
2. Add a TCP ingress rule for ipaddresses cidr1 and cidr2.
3. Deploy a VM as part of SG1.
4. Delete the existing TCP ingress rule for cidr1.

Before Step4:
We should be able to access the VM from cidr1 and cidr2.
After Step4:
We should NOT be able to access the VM from cidr1.
We should be able to access the VM from cidr2.

75

Deploy few Vms in a Security group which has an ingress rule that allows ICMP protocols for cidr1 and cidr2.
Delete the existing ingress rule for cidr1.

1.Create a Security Group SG1.
2. Add a ICMP ingress rule for ipaddresses cidr1 and cidr2.
3. Deploy a VM as part of SG1.
4. Delete the existing ICMP ingress rule for cidr1.

Before Step4:
We should be able to ping the VM from cidr1 and cidr2.
After Step4:
We should NOT be able to ping the VM from cidr1.
We should be able to access the VM from cidr2.

76

Add Ingress rules when the VM is in stopped state.

1.Create a Security Group SG1.
2. Add a TCP ingress rule for ipaddresses cidr1 and cidr2.
3. Deploy a VM as part of SG1.
4. Stop this VM.
5. Add a TCP ingress rule for ipaddresses cidr3 in SG1.
6. Start this VM.

As part of starting the VM , we should see the iptable rules being reprogrammed.
We should be able to access the VM from cidr1,cidr2 and cidr3.

77

Delete an Ingress rules when the VM is in stopped state.

1.Create a Security Group SG1.
2. Add a TCP ingress rule for ipaddresses cidr1 and cidr2.
3. Deploy a VM as part of SG1.
4. Stop this VM.
5. Delete the existing TCP ingress rule for ipaddresses cidr1 in SG1.
6. Start this VM.

Before Step4:
We should be able to access the VM from cidr1,cidr2.
We should NOT be able to access the VM from cidr3.

After Step4:
As part of starting the VM , we should see the iptable rules being reprogrammed.
We should be able to access the VM from cidr1,cidr2 and cidr3.

Account based Ingress rules

78

Deploy a VM in a Security group which has an ingress rule that allows TCP protocols for a port range for another Security Group - SG2.

1. Deploy few Vms in Security Group - SG2.
2. Create a Security Group SG1 that has a TCP ingress rules that allows port 22-80 for SG2.
3. Deploy a VM in SG1.

VM should get deployed successfully.
From all the VMs in SG2 , we should be able to access this VM on port 22 - port 80 using TCP protocol.

79

VM should be accessible using their vm name from any other VM.

1. Deploy few VM in Security Group - SG2.
2. Create a Security Group SG1 that has a TCP ingress rules that allows port 22-80 for SG2.
3. Deploy VM with display name in SG1.

VM should get deployed successfully.
From all the VMs in SG2 , we should be able to access this VM using the display name on port 22 - port 80 using TCP protocol.

80

Deploy a VM in a Security group which has an ingress rule that allows ICMP protocols for a port range for another Security Group - SG2.

1. Deploy few Vms in Security Group - SG2.
2. Create a Security Group SG1 that has a ICMP ingress rules that allows port 22-80 for SG2.
3. Deploy a VM in SG1.

VM should get deployed successfully.
From all the VMs in SG2 , we should be able to PING this VM.

81

Deploy a VM in a SG that is allowed Ingress access to another Security Group.

Pre-Red:
1. Deploy few Vms in Security Group - SG2.
2. Create a Security Group SG1 that has a TCP ingress rules that allows port 22-80 for SG2.
3. Deploy few VMs in SG1.
Steps:
1. Deploy a VM in the SG2.

This should result in the new VM's ipaddress being added to the ingress chain of all the Vms that are part of SG1.

From the new VM , we should be able to access all the Vms in SG1.

82

Stop a VM that is in a SG that is allowed Ingress access to another Security Group.

Pre-Red:
1. Deploy few Vms in Security Group - SG2.
2. Create a Security Group SG1 that has a TCP ingress rules that allows port 22-80 for SG2.
3. Deploy few VMs in SG1.
Steps:
1. Stop one of the VMS in SG2.

This should result in the stopped VM's ipaddress being removed from the ingress chain of all the Vms that are part of SG1.

83

Stop and Start a VM that is in a SG that is allowed Ingress access to another Security Group.

Pre-Red:
1. Deploy few Vms in Security Group - SG2.
2. Create a Security Group SG1 that has a TCP ingress rules that allows port 22-80 for SG2.
3. Deploy few VMs in SG1.
Steps:
1. Stop one of the VMS in SG2.
2. Start this VM.

After Step1:
This should result in the stopped VM's ipaddress being removed from the ingress chain of all the Vms that are part of SG1.
After Step2:
This should result in this VM's ipaddress being added to the ingress chain of all the Vms that are part of SG1.
From this VM , we should be able to access all the Vms in SG1.

84

Destroy a VM that is in a SG that is allowed Ingress access to another Security Group.

Pre-Red:
1. Deploy few Vms in Security Group - SG2.
2. Create a Security Group SG1 that has a TCP ingress rules that allows port 22-80 for SG2.
3. Deploy few VMs in SG1.
Steps:
1. Destroy one of the VMS in SG2.

This should result in the destroyed VM's ipaddress being removed from the ingress chain of all the Vms that are part of SG1.

85

Restore a destroyed VM that is in a SG that is allowed Ingress access to another Security Group.

Pre-Red:
1. Deploy few Vms in Security Group - SG2.
2. Create a Security Group SG1 that has a TCP ingress rules that allows port 22-80 for SG2.
3. Deploy few VMs in SG1.
Steps:
1. Destroy one of the VMS in SG2.
2. Restore this VM back.

After Step1:
This should result in the destroyed VM's ipaddress being removed from the ingress chain of all the Vms that are part of SG1.
After Step2:
This should result in this VM's ipaddress being added to the ingress chain of all the Vms that are part of SG1.
From this VM , we should be able to access all the Vms in SG1.

86

Reboot a VM that is in a SG that is allowed Ingress access to another Security Group.

Pre-Red:
1. Deploy few Vms in Security Group - SG2.
2. Create a Security Group SG1 that has a TCP ingress rules that allows port 22-80 for SG2.
3. Deploy few VMs in SG1.
Steps:
1. Reboot one of the VMS in SG2.

After Reboot is successful:
From this VM , we should still be able to access all the Vms in SG1.

CIDR based egress rules

87

Deploy a VM in a Security group which has NO egress rules.

1.Create a Security Group SG1.
2. Have no egress rules.
3. Deploy a VM as part of SG1.

1. VM deployment should succeed.
2. From this VM , we should we able to access any ipaddress. No egress traffic should be blocked.

88

Deploy a VM in a Security group which has an egress rule that allows TCP protocols for a port range for a cidr.

1.Create a Security Group SG1.
2. Add a TCP egress rule for a port range (22-80) for any ipaddress (cidr1).
3. Deploy a VM as part of SG1.

1. VM deployment should succeed.
2. From this VM , we should we able to access cidr1 using all ports from 22 -80.
3. From this VM, We should NOT be able to access any other ipadress .

89

Deploy a VM in a Security group which has an egress rule that allows ICMP protocols for 1 type and 1 code for a cidr.

1.Create a Security Group SG1.
2. Add a ICMP egress rule for any 1 type and 1 code for any ipaddress (cidr1).
3. Deploy a VM as part of SG1.

1. VM deployment should succeed.
2. Make sure that in iptables the correct type and code for ICMP is programmed.

90

Deploy few Vms in a Security group which has an egress rule that allows TCP protocols for cidr1.
Add an egress rule to allow ICMP protocols for cidr1 and cidr2.

1.Create a Security Group SG1.
2. Add a TCP egress rule for a port range (22-80) for any ipaddress (cidr1).
3. Deploy a VM as part of SG1.
4. Add an egress rule to allow ICMP protocols for cidr1 and cidr2.

Before Step4:
From this VM , we should be able to access cidr1.
From this VM , we should NOT be able allowed to PING cidr1 and cidr2.
After Step4:
From this VM , we should be able to access cidr1.
From this VM , we should be able allowed to PING cidr1 and cidr2.

91

Deploy few Vms in a Security group which has an egress rule that allows TCP protocols for cidr1 and cidr2.
Delete the existing egress rule for cidr1.

1.Create a Security Group SG1.
2. Add a TCP egress rule for ipaddresses cidr1 and cidr2.
3. Deploy a VM as part of SG1.
4. Delete the existing TCP egress rule for cidr1.

Before Step4:
From this VM , we should be able to access cidr1 and cidr2.
After Step4:
From this VM , we should be able to access cidr2.But we should not be able to access cidr1.

92

Deploy few Vms in a Security group which has an egress rule that allows ICMP protocols for cidr1 and cidr2.
Delete the existing egress rule for cidr1.

1.Create a Security Group SG1.
2. Add a ICMP egress rule for ipaddresses cidr1 and cidr2.
3. Deploy a VM as part of SG1.
4. Delete the existing ICMP egress rule for cidr1.

Before Step4:
From this VM , we should be able to ping cidr1 and cidr2.
After Step4:
From this VM , we should be able to ping cidr2.But we should not be able to ping cidr2.

93

Add egress rules when the VM is in stopped state.

1.Create a Security Group SG1.
2. Add a TCP egress rule for ipaddresses cidr1 and cidr2.
3. Deploy a VM as part of SG1.
4. Stop this VM.
5. Add a TCP egress rule for ipaddresses cidr3 in SG1.
6. Start this VM.

As part of starting the VM , we should see the iptable rules being reprogrammed.
We should be able to access the VM from cidr1,cidr2 and cidr3.

94

Delete an egress rules when the VM is in stopped state.

1.Create a Security Group SG1.
2. Add a TCP egress rule for ipaddresses cidr1 and cidr2.
3. Deploy a VM as part of SG1.
4. Stop this VM.
5. Delete the existing TCP egress rule for ipaddresses cidr1 in SG1.
6. Start this VM.

Before Step4:
From this VM , we should be able to access cidr1 and cidr2.
From this VM , we should NOT be able to access cidr3.
After Step4:
From this VM , we should be able to access cidr1,cidr2 and cidr3.

Account based egress rules

95

Deploy a VM in a Security group which has an egress rule that allows TCP protocols for a port range for another Security Group - SG2.

1. Deploy few Vms in Security Group - SG2 that has a TCP ingress rules that allows port 22-80 for SG1.
3. Create a Security Group SG1 that has a TCP egress rules that allows port 22-80 for SG2.
4. Deploy a VM in SG2.

VM should get deployed successfully.
From Vms in SG1 , we should be able to access all the Vms in SG2.
From Vms in SG1 , we should not be able to access any other Vms (vms that are part of other SG and vms that are part of the same group)

96

Deploy a VM in a Security group which has an egress rule that allows ICMP protocols for another Security Group - SG2.

1. Deploy few Vms in Security Group - SG2 that has a ICMP ingress rules that allows SG2.
2. Create a Security Group SG1 that has a ICMP egress rules that allows port 22-80 for SG2.
3. Deploy a VM in SG2.

VM should get deployed successfully.
From all the VMs in SG1 , we should be able to PING all the Vms in SG2.

97

Stop a VM that is in a SG that is allowed egress access to another Security Group.

Pre-Red:
1. Deploy few Vms in Security Group - SG2 that has a TCP ingress rules that allows SG2.
2. Create a Security Group SG1 that has a TCP egress rules that allows port 22-80 for SG2.
3. Deploy few VMs in SG1.
Steps:
1. Stop one of the VMS in SG2.

This should result in the stopped VM's ipaddress being removed from the egress chain of all the Vms that are part of SG1.

98

Stop and Start a VM that is in a SG that is allowed egress access to another Security Group.

Pre-Red:
1. Deploy few Vms in Security Group - SG2 that has a TCP ingress rules that allows SG2.
2. Create a Security Group SG1 that has a TCP egress rules that allows port 22-80 for SG2.
3. Deploy few VMs in SG1.
Steps:
1. Stop one of the VMS in SG2.
2. Start this VM.

After Step1:
This should result in the stopped VM's ipaddress being removed from the egress chain of all the Vms that are part of SG1.
After Step2:
This should result in this VM's ipaddress being added to the egress chain of all the Vms that are part of SG1.
From this VM , we should be able to access all the Vms in SG1.

99

Destroy a VM that is in a SG that is allowed egress access to another Security Group.

Pre-Red:
1. Deploy few Vms in Security Group - SG2 that has a TCP ingress rules that allows SG2.
2. Create a Security Group SG1 that has a TCP egress rules that allows port 22-80 for SG2.
3. Deploy few VMs in SG1.
Steps:
1. Destroy one of the VMS in SG2.

This should result in the destroyed VM's ipaddress being removed from the egress chain of all the Vms that are part of SG1.

100

Reboot a VM that is in a SG that is allowed egress access to another Security Group.

Pre-Red:
1. Deploy few Vms in Security Group - SG2.
2. Create a Security Group SG1 that has a TCP egress rules that allows port 22-80 for SG2.
3. Deploy few VMs in SG1.
Steps:
1. Reboot one of the VMS in SG2.

After Reboot is successful:
From this VM , we should still be able to access all the Vms in SG1.

101

Deploy a VM in a Security group that allows for all Vms with in the Security Group to communicate with each other

1. Create a Security Group SG1 that has a TCP ingress rules that allows port 22-80 for SG1.
2. Deploy few VMs in SG1.

VM should get deployed successfully.
All the Vms on SG1 , should be able to communicate with each other on TCP protocol for port 22-80.

102

Deploy a VM in a Security group that allows for all Vms with in the Security Group to communicate with each other. This Security Group should also have restricted egress access to few other cidrs.

1. Create a Security Group SG1 that has a TCP ingress rules that allows port 22-80 for SG1.
2. Deploy few VMs in SG1.
3. Add an egress rule for cidr1.
4. Add another egress rule for allowing SG1.

After Step2:
All the Vms on SG1 , should be able to communicate with each other on TCP protocol for port 22-80.
After Step3:
All the Vms on SG1 , should NOT be able to communicate with each other on TCP protocol for port 22-80.
All the Vms should be able to access cidr1.
All the Vms should NOT be able to access any other ipaddress other than cidr1.
After Step4:
All the Vms on SG1 , should be able to communicate with each other on TCP protocol for port 22-80.
All the Vms should be able to access cidr1.
All the Vms should NOT be able to access any other ipaddress other than cidr1.

Space shortcuts

Child pages

Versions Compared

Old Version 1

New Version 2

Key