Module 4 - Introduction to XenServer Storage Repositories

Transcription

1 Module 4 - Introduction to XenServer Storage Repositories Page 1

2 Table of contents Scenario... 3 Exercise 1: Creating an NFS Storage Repository... 4 Exercise 2: Probing an Storage Repository... 9 Exercise 3: Detach and Reattach a Storage Repository Exercise 4: Forget and Introduce a Storage Repository using the CLI Exercise 5: Configure a Dedicated Storage Network Interface Exercise 6: Configure Multipathing Exercise 7: Review volumes and virtual disks Exercise 8: Migrate a virtual disk (VDI) Exercise 9: Create and Resize a Virtual Disk Page 2

3 Scenario You work for an Infrastructure as a Service (IaaS) provider and have been tasked with the configuration of the virtualization infrastructure based on XenServer. The base installation of XenServer has been completed and you are now in a position to configure the storage system for use in the environment. You are also required to review the configuration to confirm functionality and perform administrations tasks in support of the hosted virtual machines. The requirements are that administrators of virtual machines need to me agile and move between servers without interrupting their services. Page 3

4 Exercise 1: Creating an NFS Storage Repository In this exercise we will create an NFS shared Storage Repository that will allow for virtual machine images (disks/vdis) to be stored and accessed from an NFS share. This SR will be available to a XenServer host or all hosts in a XenServer pool. Step-by-step guidance Estimated time to complete this lab: 5 minutes. Step Action Create a new NFS storage repository via XenCenter 1. Using XenCenter click New Storage. 2. Select NFS VHD and click Next. Page 4

5 3. Keep the default name NFS virtual disk storage and click Next. Note: By default a description will be auto-generated based on information you provide in the wizard. 4. Enter the vstorage server IP and path to the export/share; :/nfs 5. Click Scan. 6. No advanced options will be specified at this time. Page 5

6 7. Select Create a new SR and click Finish. Note: All existing SRs detected on the NFS export/share will be listed and can be reattached. 8. Confirm the NFS SR has been attached to the pool. Page 6

7 9. Right-click Shared VM Storage and click Set as Default. 10. On the General tab for the new SR expand the Status drop down field and confirm all hosts in the pool are connected to the SR. Note: An NFS SR is not capable of using Multipathing. Page 7

8 Key takeaways The key takeaways for this exercise are: You will be able to create an NFS SR to store virtual machine images (disks/vdis) You will be able to set a default SR which is used to store crash dump data and images of suspended VMs, and which will be the default SR used for new virtual disks. Notes The Advanced Options field allows administrators to configure the transport protocol to UDP using the useudp=true parameter. Note that it is possible to use different SRs for VMs, crash dump data and suspended VM using the XenServer xe command line interface (CLI). See the XenServer Administrator's Guide for more information. Page 8

9 Exercise 2: Probing an Storage Repository Overview In this exercise we probe an iscsi and NFS SR to confirm the iscsi IQN of the target, confirm which LUN or export has been exposed to the XenServer host, and whether it contains an existing storage repository. Step-by-step guidance Estimated time to complete this lab: 15 minutes. Step Action Use sr-probe to review iscsi server accessible LUN information 1. From the landing desktop launch an SSH session using PuTTY and connect to vxs01 2. Execute the following: xe sr-probe type=lvmoiscsi device-config:target= Note: For steed and accuracy it is recommended to copy and paste commands from the lab guide into your lab. 3. The output from the command will provide the Target IQN of the iscsi Target. Page 9

10 4. Now that we have the IQN execute the following: xe sr-probe type=lvmoiscsi device-config:target= deviceconfig:targetiqn=iqn com.storage:server.target1 5. The output from this command will provide the SCSI IDs for the LUNs available on the target. 6. Now that we have the SCSI ID execute the following: xe sr-probe type=lvmoiscsi device-config:target= deviceconfig:targetiqn=iqn com.storage:server.target1 deviceconfig:scsiid=1iet_ The output from this command will provide information on existing SRs on the LUN. 8. Use sr-probe to locate NFS server export/share information 9. Using the SSH connection, execute the following command to view available exports: xe sr-probe type=nfs device-config:server= Page 10

11 10. The output from the command will list the target export, export path, and access list i.e. which IPs or hosts can access the export. Note: In this example the export/share /nfs is accessible by all IPs as represented by the * wildcard/asterisk. Key takeaways The key takeaways for this exercise are: Probe an iscsi target via the CLI Confirm the IQN of a target storage service or device, confirm which LUN is available to the server, and confirm whether any existing SR are located on the LUN. Probe an NFS server via the CLI Confirm the exports provided by NFS server Page 11

12 Exercise 3: Detach and Reattach a Storage Repository Overview In this exercise you will detach a storage repository from a hosts and/or pool. Detaching an SR allows for an Administrator to migrate an SR to a different host or pool and to perform maintenance on an SR. You will perform these steps by using XenCenter and the CLI. Step-by-step guidance Estimated time to complete this lab: 15 minutes. Step Action Detach and SR using XenCenter 1. Using XenCenter select the NFS virtual disk storage SR in the Infrastructure pane and click the Storage tab. 2. Click Add Page 12

13 3. Name the virtual disk nfs-disk1, specify 2GB as the size, enter a description NFS Virtual disk used for demo, and ensure the NFS virtual disk storage SR is selected in the location: field. 4. Click Add 5. Confirm the virtual disk was created. Note: The Virtual Machine field is empty as this virtual disk/vdi is not currently attached to any virtual machines. Page 13

14 6. Right-click on the NFS SR and click Detach. 7. Review the warning message and click Yes to confirm. Page 14

15 8. Confirm the SR has been detached by the state icon and the Status field on the General tab in XenCenter. 9. Repair a storage repository using XenCenter 10. Select the NFS virtual disk storage which is currently detached. 11. Right-click the SR and select Repair Page 15

16 12. Review the status of the SR, all hosts should be Unplugged 13. Click Repair Page 16

17 14. Repair process should complete with all hosts in the pool Connected to the SR 15. Close the Repair wizard when connection to the SR is repaired. 16. Confirm the SR is connected and select the NFS SR Storage tab. 17. Confirm the nfs-disk1 is again available 18. Forget an SR using XenCenter 19. Right-click on the NFS SR and select Detach 20. Click Yes on the warning message Page 17

18 21. Confirm the SR is detached/unplugged from all hosts 22. Right-click on the detached SR and select Forget 23. Review the warning and click Yes, Forget Reattaching an existing SR 24. Click New Storage 25. Select NFS VHD SR type and click Next 26. Leave all fields default and click Next 27. Enter share name :/nfs 28. Click Scan Page 18

19 29. Select Reattach an existing SR and highlight the SR UUID listed 30. Click Finish 31. Review the warning message and click Yes Page 19

20 32. Confirm the SR has been reattached and set the SR as Default 33. Select the Storage tab 34. Confirm a 2GB virtual disk is available. Note: The name and description you provided is no longer available and was lost as part of the Forget process. 35. Select the virtual disk and click Properties Page 20

21 36. Name the disk nfs-disk1 and add a description demo disk 37. Confirm the name and description is added to the disk 38. Detach a storage repository via CLI 39. Using your SSH connection to vxs01 locate the PBD associated with the NFS SR by running the following command: xe pbd-list host-name-label=vxs01 Page 21

22 40. Locate and note the PBD UUID that references the NFS server path in the device-config field. 41. Now that we know the PBD UUID run the following command: xe pbd-unplug uuid=<pbd UUID>. (Remember to use tab-completion for UUIDs by entering the first 4 characters of a UUID and press TAB e.g. 4483) Note: the command should complete without any confirmation or error message 42. Confirm the PDB is unplugged by running: xe pbd-list uuid=<pbd UUID> params=all Note: the currently-attached field should state false Page 22

23 43. Switch to XenCenter and confirm the NFS SR is detached Note: as we only unplugged the PBD for vxs01 it is the only host in the pool that is disconnected from the SR. 44. Reconnect a storage repository using CLI 45. Switch back to the SSH connection 46. Reconnect/Repair the SR using the CLI run the following command: xe pbd-plug uuid=<pbd UUID that was unplugged> Note: the command should complete without any message Page 23

24 47. Navigate to XenCenter and confirm that the SR is now reconnected to host vxs01 Key takeaways Notes The key takeaways for this exercise are: Detach an SR via XenCenter Reattached an SR via XenCenter Detach an SR vie the CLI Reattached an SR via CLI Page 24

25 Exercise 4: Forget and Introduce a Storage Repository using the CLI Overview In this exercise you will detach a storage repository (SR) from a pool and forget the association data for the SR. You will then reintroduce an SR via the CLI preserving any existing data on the SR. This process includes creating an SR object, creating a physical block device (PBD) object, and plugging these objects into a pool. Step-by-step guidance Estimated time to complete this lab: 15 minutes. Step Action 1. Forget an SR 2. Select the NFS SR in the Resources pane 3. Right-click and click Detach 4. Click Yes. As per the previous exercise the SR will be detached. 5. Right-click on the detached SR and click Forget. 6. Review the warning message and click Yes, Forget to confirm. 7. Introduce and SR Page 25

26 8. Unlike detaching and reattaching an SR, forgetting an SR will remove the data that matches a virtual disk to a virtual machine. Although it is possible to recreate the SR as in previous exercise we will reintroduce and SR using the CLI. Probe the NFS storage server to locate the exports available: xe sr-probe type=nfs device-config:server= Probe the export for existing SRs on the export: xe sr-probe type=nfs device-config:server= deviceconfig:serverpath=/nfs Page 26

27 11. Using the detail collected from the sr-probe reintroduce the SR: xe sr-introduce content-type=user type=nfs name-label= NFS virtual disk storage shared=true uuid=<uuid from probe> TIP: copy the SR UUID from the probe output by highlighting the UUID and right-click the shell. Note: The output of this command will be a SR UUID you will use in the next step. Page 27

28 12. Switch to XenCenter and confirm the SR status: Page 28

29 13. Create a PBD between the host and the SR: xe pbd-create device-config:server= deviceconfig:serverpath=/nfs sr-uuid=<uuid of SR-introduce> host-uuid=<uuid of vxs01> TIP: now that the SR UUID was created using the Introduce command you can use TAB completion for the UUIDs in this command. TIP: get a host UUID for a host from General tab in XenCenter. Note: the output of this command will be a PBD UUID you will use in the next step. Page 29

30 14. Switch back to XenCenter and confirm the Status of the SR: 15. Plug the PBD to the hosts: xe pbd-plug uuid=<uui of PBD you created) Page 30

31 16. Switch back to XenCenter and confirm the Status of the SR: 17. When using the CLI the PBD creation process needs to be completed on all other hosts in the pool. To speed up this process we will use XenCenter to repair the SR. Right-click the NFS SR and select Repair Page 31

32 18. Click Repair. 19. Confirm the PBD were automatically created and the SR is Connected and click Close. 20. Set the NFS SR as Default Page 32

33 Key takeaways Notes The key takeaways for this exercise are: You will be able to Forget an SR You will be able to introduce an SR You will be able to create a PBD You will be able to Plug a PBD You will be able to repair an SR All these introduction steps will have to be completed on each hosts in the pool. The preferred method to work around this is to use the Repair option in XenCenter to create and attach the required PBDs for the rest of the hosts. Page 33

34 Exercise 5: Configure a Dedicated Storage Network Interface Overview In this exercise we will create and configure a pool wide Secondary Interface which is dedicated to storage traffic. When you want to dedicate a secondary interface for a specific purpose, you must ensure the appropriate network configuration is in place to ensure the NIC is used only for the desired traffic. For example, to dedicate a NIC to storage traffic, the NIC, storage target, switch, and/or VLAN must be configured so that the target is only accessible over the assigned NIC. If your physical and IP configuration do not limit the traffic that can be sent across the storage NIC, it is possible to send other traffic, such as management traffic, across the secondary interface. Step-by-step guidance Estimated time to complete this lab: 10 minutes. Step Action 1. Using XenCenter select the pool node Page 34

35 2. Select the Networking tab 3. Click Configure Page 35

36 4. Click Add IP address 5. Name the secondary interface Storage Network 6. Select Network 2 7. Enter the following IP address information: IP address range: Subnet mask: Gateway: <leave blank> Note: the additional IP listed that will be assigned to the members servers in the pool. 8. Click OK Page 36

37 9. Confirm each server in the pool has a dedicated storage network created. 10. Ping each servers in the pool using the new IP to confirm communication. Note: use either the host console tab in XenCenter or the SSH connection. The key takeaways for this exercise are: Key takeaways Notes You will be able to designate and configure a pool wide dedicated storage network When selecting a NIC to configure as a secondary interface for use with iscsi or NFS SRs, ensure that the dedicated NIC uses a separate IP subnet that is not routable from the management interface. If this is not enforced, then storage traffic may be directed over the main management interface after a host reboot, due to the order in which network interfaces are initialized. For more information review the Configuring a Dedicated Storage NIC section in the admin guide. Page 37

38 Exercise 6: Configure Multipathing Overview In this exercise you will enable multipathing within the pool. Configuring multipathing helps provide redundancy for network storage traffic in case of partial network or device failure. The term multipathing refers to routing storage traffic to a storage device over multiple paths for redundancy (failover) and increased throughput. Step-by-step guidance Estimated time to complete this lab: 20 minutes. Step Action Configure Multipathing 1. Using XenCenter right-click server vxs03 and select Enter Maintenance Mode Page 38

39 2. Click Enter Maintenance Mode 3. Repeat step 1-2 for server vxs02 and lastly vxs01. All server should now be in maintenance mode. 4. A host cannot enter maintenance mode with running VM. Leave the Maintenance Mode windows open and Shut Down the Demo Linux 2 VM. Page 39

40 5. Click Enter Maintenance Mode on the pool master. Note: there will be a short delay while XenCenter migrates any active virtual machines and unplugs the existing storage; if the server is a pool master, it will be disconnected and may disappear from the Resources pane temporarily while a new pool master is assigned. 6. Right-click vxs01 and select Properties Page 40

41 7. Select Multipathing and tick Enable multipathing on this server and click OK Note: when enabling multipathing all SRs need to reattach. This can be confirmed in XenCenter: 8. Repeat step 6 and 7 for server vxs02 and lastly vxs03. All server should now have multipathing enabled. Wait for the process to complete on a server before moving to the next server. 9. Right-click on server vxs01 and click Exit Maintenance mode. Page 41

42 10. Select Skip Note: as we shut down the VM during while running the Maintenance wizard XenCenter will prompt to restore the VM to the host. 11. Complete the previous step for vxs02 and vxs03. All hosts in the pool should now be out of Maintenance mode. Page 42

43 12. Select the iscsi SR and expand the Multipathing field. Notice that only 1 path is available per server. 13. For some storage server/devices manual configuration is required via CLI. Switch to or Connect to SSH session to server vxs Use the iscsiadm command to discover the available targets on the vstorage server: iscsiadm -m discovery -t st p Note: -t refers to the type, st refers to the sendtargets parameter (it must always be sendtargets); -p refers to the ip:port parameter. Note: for more information on the iscsiadm command use man iscsiadm. Page 43

44 15. Discover the target available for IP : iscsiadm -m discovery -t st -p Note: the same iscsi target is accessible from both IPs (dedicated storage network and management network). In a real-world scenario the dedicated storage network should be isolated from all other traffic including management and VM traffic. 16. Manually login to the targets: iscsiadm -m node --login Note: In our lab we have 1 target. If the vstorage server (TGT iscsi Target) had multiple targets available you would specify the target IQN as part of this command. The errors are expected as a 1 session already existed prior to executing the command. 17. Switch to XenCenter; select the iscsi SR and confirm the current Multipath status Note: as we have manually logged on vxs01 it now shows two paths. Page 44

45 18. Repeat steps on all servers vxs02 and vxs Switch to XenCenter; select the iscsi SR and confirm the current Multipath status 20. Review multipath status via the CLI 21. Switch to your SSH connection Page 45

46 22. Confirm there are two sessions from the host to the target: iscsiadm -m session Note: using this command we can see we have two sessions although XenCenter indicates one. 23. Review additional details relating to the iscsi sessions: iscsiadm -m session -P3 Note: this command lists detailed information about the current iscsi sessions Page 46

47 24. List the paths as seen by multipath: multipath ll Note: the errors in the output is due to a bug in the multipath.conf file which is fixed in later versions. 25. Although it is recommended to use the multipath command you can also list the paths using mpathutil: mpathutil status Key takeaways Notes The key takeaways for this exercise are: You will be able to enable multipathing on a per-host basis You will be able to manually login to an iscsi target You will be able to review the current multipathing status Page 47

48 Exercise 7: Review volumes and virtual disks Overview In this exercise you will review the layout of virtual disks in XenServer. You will review the LVM layout used by XenServer for managing virtual disks and the virtual disk objects (VDI) managed by XAPI. Step-by-step guidance Estimated time to complete this lab: 15 minutes. Step Action 1. Connect to vxs01 or switch to SSH session 2. Display and review the physical volume information for the host: pvs Note the physical volume (PV) path, volume group (VG) name, and physical size (Psize). 3. Display and review additional information about the physical volume: pvdisplay Page 48

49 4. Display and review the volume group information for the host: vgs Note: that in this configuration there is one logical volume that spans the whole physical volume. On this logical volume we implement the EXT filesystem. 5. Display and review additional information about the volume group: vgdisplay Page 49

50 6. Display and review the logical volumes in the pool: 7. Display and review additional information on the logical volumes in the pool: Note: in the lab we have a logical volume for the Local SR which has an EXT file system loaded on top. This provide support for IntelliCache. We can also see the logical volume (virtual disks) on the iscsi SR with the VG Name VG_XenStorage Page 50

51 8. Display and review all current snapshots in the pool: xe snapshot-list 9. List the parameter of the Initial Status snapshot you took: xe snapshot-list uuid=<uuid of Initial Status snapshot> params=all Page 51

52 10. Locate the VM UUID of the snapshot to by reviewing the field name. This indicates which VM the snapshot belongs to: snapshot-of ( RO): < uuid> 11. List all the virtual disks and VBDs associated with the specific VM: xe vm-disk-list uuid=<vm UUID> Note: the output lists the VBD which is the disk connection to the VM and the VDI which represents the virtual disk. Page 52

53 12. List all the parameters of a virtual disk (VDI) xe vdi-params-list uuid=<vdi of VM> 13. Locate vhd-parent VDI UUID from the sm-config field Page 53

54 14. Use the vhd-util tool to list the associations between or VHD tree for the virtual disks: TIP: use the vgs command to locate the volume group name of the iscsi SR required in this step. vhd-util scan -fpm "VHD-*" -l VG_XenStorage-<UUID> TIP: remember to use the highlight+right-click action to copy the VG (volume group) name. 15. From the output, locate the virtual disk UUID of the snapshot/child VHD and the UUID of the Parent VHD 1 TIP: you can review all disk/storage related activities by monitoring the Storage Manager (SM) log files /var/log/smlog Page 54

55 16. Switch to XenCenter and start the Demo Linux 1 VM on server vxs Select Snapshots tab and delete all snapshots you created previously. Page 55

56 18. Locate the call information in the SM logs on vxs01 and review the associated actions: less /var/log/smlog grep ia10 deletion 19. Locate and review the VHD tree information in the SM logs on vxs01 less /var/log/smlog grep i tree A5 Page 56

57 Key takeaways Notes The key takeaways for this exercise are: You will be able to locate and review the LVM layout on a host Review snapshot objects and virtual disks Review the VHD tree/child-parent relationship When deleting a child virtual disk the coalescing process is automatically initiated. This process can be reviewing in the SM log file. For more information on coalescing and methods to manually trigger the process review the admin guide. Page 57

58 Exercise 8: Migrate a virtual disk (VDI) Overview In this exercise you will move the Virtual Disk Image (VDI) of a running VM from iscsi shared storage to NFS shared storage, without moving the VM. This process can be used by Administrators when migrating disks to different storage tiers. The potions available for moving a VDI depends on the VM state i.e. running or shut down and you will review these options for moving a VDI between Storage Repositories. Step by step guidance Estimated time to complete this lab: 15 minutes. Step Action 1. Using XenCenter select the running Demo Linux 1 VM 2. Select the console node and login (root/citrix123) 3. Configure a static IP address ( ): nano /etc/sysconfig/network-scripts/ifcfg-eth0 vi /etc/sysconfig/network-scripts/ifcfg-eth0 Page 58

59 Step Action 4. Configure a gateway address ( ): nano /etc/sysconfig/network or vi /etc/sysconfig/network 5. Restart network service: /etc/init.d/network restart Note: the error on eth1 is expected as the interface is set to be loaded on boot. 6. Initiate a ping to a public IP address to verify liveness: ping Select the Storage tab Page 59

60 Step Action 8. Highlight the virtual disk attached to the running VM 9. Click Move 10. Select the NFS virtual disk storage repository from the list of available locations: Page 60

61 Step Action 11. Click Move Note: you can also migrate the virtual disk to local storage if required. 12. Note the icon for the VM changes as the virtual disk is migration between storage repositories. 13. Switch the to the console tab and confirm the ping is still active. Page 61

62 Step Action 14. Confirm the virtual disk now resides on the NFS SR using the VM storage tab: Note: the same process can be initiated directly from the SR node and has the same result. 15. Select the Demo Linux 1 VM and shut it down 16. In the Storage tab, notice that the Move option is not available when the VM is shut down Page 62

63 Step Action 17. Right click on the VM and select Move VM 18. Select the iscsi SR 19. Click Move Note: you can also migrate the virtual disk to local storage if required. Note: the progress indicator at the bottom of XenCenter. You can also follow the Move process in the Notifications node in XenCenter. Page 63

64 Summary Key Takeaways NOTES The key takeaways for this exercise are: You have created NFS shared storage for Pool A. You will be able to move a virtual disk between shared storage SRs. You will be able to move a virtual disk from shared storage to local storage SR. There are a number of cases whereby just moving the storage alone is required and not moving the VM itself from one XenServer to another. A good example of this is moving storage from a development NAS or SAN to a production SAN. If a storage appliance is upgraded or replaced, it may also be desirable to keep VMs on the servers they reside on and just migrate the storage. Page 64

65 Exercise 9: Create and Resize a Virtual Disk Overview In this exercise we will resize the virtual disk (VDI) size for a Linux virtual machine. Storage on XenServer VMs is provided by virtual disks. A virtual disk is a persistent, on-disk object that exists independently of the VM to which it is attached. Virtual disks are stored on XenServer Storage Repositories (SRs), and can be attached, detached and re-attached to the same or different VMs when needed. New virtual disks can be created at VM creation time (from within the New VM wizard) and they can also be added after the VM has been created from the VM's Storage tab. In many cases an administrator will be required to increase the disk size of a particular virtual machine i.e. to store memory dump files, etc. We will resize our Windows 7 virtual machine via XenCenter and extend it using Disk Management. We will then increase our Linux virtual machine disk size via the XenServer host CLI and extended it using the Linux fdisk. Step-by-step guidance Estimated time to complete this lab: 20 minutes. Page 65

66 Step Action 1. In this exercise we will use a VM running on our physical host and not the virtual XenServer VMs. Shut down the Win 7-2 VM and click on the Storage tab. 2. Select the virtual disk (VDI) and click Properties and select Size and Location node. Page 66

67 Step Action 3. Increase the disk size to 30GB by changing the Size parameter and click OK. 4. The change should now be reflected in the Store information tab. 5. There are two options for extending the volume for Windows machines to utilize the additional space allocated i.e. via the Disk Management GUI or via CLI command diskpart. 6. Let s review how to complete the task via the Disk Management GUI. Start the Win7-2 VM and login as user 1 ia the Console tab. Right click on Start > Computer and select Manage Page 67

68 Step Action 7. In Computer Management select Disk Management. Confirm the additional space allocated (6GB) is detected. Page 68

69 Step Action 8. Right click on the active C partition and select Extend Volume Page 69

70 Step Action 9. Click Next Page 70

71 Step Action 10. Extend the partition to maximum size by using the default settings. Click Next. Page 71

72 Step Action 11. Click Finish Page 72

73 Step Action 12. Confirm the partition has been extended. Resize your Demo Linux 2 VM virtual disk (VDI) via XenServer host CLI Page 73

74 Step Action 13. Ensure the Demo Linux 2 VM is shut down. 14. Connect to vxs01 via a SHH (PuTTY) Page 74

75 Step Action 15. Locate the VDI UUID for the Demo Linux 2 VM that we will resize: xe vm-disk-list vm=demo\ Linux\ 2 Note: In the above example the Demo Linux 2 VM has two VDIs associated with it (swap and root). We will increase the size of the root partition. We can locate the correct VDI by comparing the disk sizes to find the correct UUID i.e. root= 4GB and swap=512mb. Note: For each VDI listed an associated VBD is displayed. 16. Extend the VDI size by 2 GB xe vdi-resize uuid=[uuid of VDI] disk-size=6gib Note: The disk size needs to be specified in GibiBytes (Binary size value) i.e. GiB Page 75

76 Step Action 17. Confirm the resize was completed successfully by listing the VDI again: xe vm-disk-list vm=demo\ Linux\ 2 Extend the volume of your Linux VM 18. Start and login to Demo Linux 2 VM Page 76

77 Step Action 19. List the amount of disk space free on the file system of the VM df- h Note: We will still see the original size value 20. List the partition information fdisk l Note: We can now see the additional space available for /dev/xvda 21. Extend the file system using resize2fs resize2fs /dev/xvda1 Page 77

78 Step Action 22. Confirm the file system size has increased using the df command df h Summary Key Takeaways Notes The key takeaways for this exercise are: You will be able to resize a virtual disk using XenCenter. You will be able to resize a virtual disk using the CLI. You will be able to extend a partition using diskpart for Windows VMs and fdisk for Linux VMs. You will be able to resize a Linux file system using resize2fs. Virtual disks on paravirtualized VMs (that is, VMs with XenServer Tools installed) can be "hotplugged", that is, you can add, delete, attach and detach virtual disks without having to shut down the VM first. VMs running in HVM mode (without XenServer Tools installed) must be shut down before you carry out any of these operations; to avoid this, you should install XenServer Tools on all HVM virtual machines. Page 78