Virtualization Blog

Discussions and observations on virtualization.
Featured

Citrix Announces General Availability of XenServer 7.5 CR

Hello everyone,

This week Citrix released the latest version of XenServer: 7.5 CR. For those unfamiliar with the LTSR and CR release models offered by Citrix, please refer to the recent article published on the Citrix blogs that explains the difference between the two release models.

So what’s new in 7.5 you may be asking? Great question!

Before I answer this question however, I’d like to remind everyone of the many features we’ve introduced since the release of 7.1 (LTSR) back in February 2017, starting with 7.1 itself.

7.1 LTSR features:

  • Automated updates to simplify host maintenance
  • Delivering Windows VM drivers via Windows updates (WSUS)
  • Health Check (via Citrix Insight Services) to monitor the health of XenServer hosts
  • Live-Patching, enabling hosts to be updated (patched) without rebooting to minimize downtime
  • PVS-Accelerator -reducing/eliminating boot storms while dramatically improving virtual desktop performance
  • SMB storage, providing even more options for SRs
  • Bitdefender Hypervisor Introspection (HVI), which scans raw memory at the hypervisor later to detect and protect virtual environments from sophisticated IT attacks (i.e., viruses, malware, ransomeware and rootkit exploits)
  • Support for Nutanix, combining the benefits of a single software stack (XA/XD/XS) with the cost-effective scale and management benefits provided by hyper-converged infrastructure

7.2 CR features:

  • Windows Continuum (tablet mode enablement) – providing seamless transition from desktop to tablet mode on virtual desktops
  • Scheduled snapshots for greater control and more flexible backup capabilities

7.3 CR features:

  • Citrix Director integration to simplify troubleshooting of virtual desktop issues
  • Bromium Secure Platform - providing advanced protection for Windows VMs
  • XenCenter host status and licensing visibility
  • Expanded Linux template support
  • VLAN tagging for management and storage interfaces to improve network utilization

With the release of 7.4 CR, XenServer became the first hypervisor to support vGPU-accelerated VM Live-Migration (XenMotion)! In addition, 7.4 introduced support for AMD MxGPU, further extending its support for the major graphics vendors (NVIDIA, Intel, AMD). Combined, these features reinforced XenServer’s lead in advanced virtual graphics capabilities.

Now that we’ve reviewed the many features that have been introduced since 7.1, let’s highlight what’s new in 7.5.

First and foremost, 7.5 introduces support for GFS2. With GFS2 support comes several experimental features, including thin provisioning on block storage for virtual disk storage repositories, as well as a significant increase in virtual disk size: from 2TBs to 16TBs. Yes, that’s correct… an 8x increase in storage capacity to help our customers with their ever-increasing data requirements!

With newly added support for Networking SR-IOV: Pass-Through of Virtual Functions, XenServer can now use Single Root I/O Virtualization that allows a single PCI device to appear as multiple PCI devices on the physical system. By assigning one or more VFs to a VM, the guest OS can use the device(s) as if it was directly assigned.

For large-scale virtual environments, customers can now take advantage of the significant increase in the number of supported hosts per XenPool – from the current limit of 16 to as many as 64.

7.5 introduces support for USB Pass-Through, enabling physical USB devices to be passed through to a VM so the guest OS can use the physical USB device as a local USB device.

Lastly, several changes have been made in 7.5 pertaining to guest OS support, including the addition of the following Linux guest OS templates:

  • CentOS 7.4
  • CentOS 6.9
  • Oracle Linux 6.9
  • Red Hat Enterprise Linux 6.9
  • Scientific Linux 6.9

Please note the majority of the features described above are available in XenServer 7.5 Enterprise edition only. For more information regarding the newest features in 7.5, refer to the Release Notes.

As you can see, XenServer continues to push the envelope when it comes to ease-of-use, security, graphics, performance, and scalability. And there are a lot more great things coming your way in future releases!

Until next time,

Andy

 

Recent Comments
Martin Cerveny
vgpu-*.src.rpm is missing in XenServer-7.5.0-source.iso. Where to find it ?
Saturday, 02 June 2018 08:47
Andy Melmed
Hi Martin, Thank you for your inquiry. As we received several inquiries asking why the vgpu-*.src.rpm is missing from the 7.5 so... Read More
Thursday, 07 June 2018 15:05
Continue reading
1123 Hits
2 Comments

XenServer 7.4 Available for Download!

Hello XenServer community,

It is our pleasure to announce the release of 7.4, the latest update in the CR release track.

XenServer 7.4 offers customers following the CR release track access to the latest product features designed to enhance application, desktop and server virtualization deployments. For customers running XenServer 7.3 (up until now the most recent CR), Citrix recommends upgrading to 7.4 at the earliest convenience to maintain support.

For customers following the LTSR release track (starting with XenServer 7.1 LTSR), Citrix recommends reviewing the XenServer 7.4 release notes to determine if 7.4 would deliver additional benefits to their virtual environments.

Note: The decision to embark on the CR release track entails the adoption of new CRs as they are made available in order to maintain support, as hotfixes for each CR are only made available for up to 4 months after the next CR is released. Please see the XenServer Product Lifecycle page for details.

XenServer 7.4 is available in the following editions:

  • Free Edition
  • Standard Edition
  • Enterprise Edition

IMPORTANT NOTICE FOR XENSERVER FREE EDITION USERS

The release of 7.3 introduced several changes to feature availability in the Free Edition of XenServer. For details regarding these changes, please see XenServer 7.3: Changes to the Free Edition.

NEW FEATURES IN XENSERVER 7.4

The following features and functionality are new in XenServer 7.4:

  • vGPU-enabled VM live-migration (XenMotion)
  • AMD MxGPU support
  • Citrix Cloud XenApp/XenDesktop subscriptions to XenServer (licensing)

For more information, including the edition(s) in which each feature can be found, refer to the XenServer 7.4 release notes.

To download XenServer 7.4, please visit the XenServer Product Download page.

Cheers!

Andy

 

Recent Comments
Ilsa Loving
Why is 7.1 no longer available? I thought it was supposed to be an LTSR version. While the removal of features was dissappointin... Read More
Wednesday, 07 March 2018 01:03
David Cottingham
Hi Ilsa, Back in August last year Citrix announced that hotfixes on each release would be available to Free Edition customers unt... Read More
Thursday, 08 March 2018 01:26
Andreas Becker
Where are the nVidia Grid drivers for XenServer 7.4 ??? Can´t find them at nVidia Enterprise Licensing Portal ...
Thursday, 15 March 2018 17:35
Continue reading
8942 Hits
4 Comments

Announcing the Availability of XenServer 7.3

We're pleased to announce the availability of XenServer 7.3, the latest Current Release (CR)!

CRs Versus LTSRs

XenServer 7.3 offers customers following the CR release track access to the latest product features designed to enhance application, desktop and server virtualization deployments. For customers running XenServer 7.2 (up until now the most recent CR), Citrix recommends upgrading to 7.3 at the earliest convenience to maintain support.

For customers following the LTSR release track (starting with XenServer 7.1 LTSR), Citrix recommends reviewing the XenServer 7.3 release notes to determine if 7.3 would deliver additional benefits to their virtual environments.

Note: The decision to embark on the CR release track entails the adoption of new CRs as they are made available in order to maintain support, as hotfixes for each CR are only made available for up to 4 months after the next CR is released. See the XenServer Product Lifecycle page for details.

XenServer 7.3 is available in the usual three editions:

  • Free Edition
  • Standard Edition
  • Enterprise Edition

Important Notice for XenServer Free Edition Users

With the release of 7.3 comes several changes to feature availability in the Free Edition of XenServer. For details regarding these changes, please see XenServer 7.3: Changes to the Free Edition.

New Features in XenServer 7.3

The following is a list of the features and functionality introduced in XenServer 7.3:

  • Enhanced security for Windows virtual machines by support for Bromium Secure Platform
  • Changed Block Tracking API (for enhanced backups)
  • New and expanded guest OS support
  • Support for VLAN tagging on management and storage network interfaces
  • IGMP snooping for IPv4 multicast support
  • SMB v3.0 for ISO storage repositories (SRs)
  • Improvements to XenServer Conversion Manager
  • Localization for Email Performance Alerts
  • Support for BIOS Asset Tags
  • Citrix Director integration
  • Enablement for XenDesktop Tablet Mode (enables Windows 10 Continuum experience in virtualized desktop environments)

For more information, including the edition(s) in which each feature can be found, please refer to the XenServer 7.3 release notes.

To download XenServer 7.3, please visit the XenServer Product Download page.

Cheers!

Andy

 

Continue reading
6869 Hits
0 Comments

A Great Time to Take A Look at XenServer Enterprise!

Good afternoon everyone,

As we make our way through the last quarter of the year, I wanted to remind the community of the significant progress the XenServer team has achieved over the last 18 months to make XenServer the awesome hypervisor that it is today!

While many of you have been making the most of your free XenServer hypervisor, I would like to take this opportunity to review just a few of the new features introduced in the latest releases of the Enterprise edition - features that our customers have been using to optimize their application and desktop virtualization deployments.

For starters, we've instrumented automated updates and live patching, features that streamline the platform upgrade process by enabling multiple fixes to be installed and applied with a single reboot and in many cases, no reboot whatsoever, significantly reducing downtime for environments that require continuous uptime.

We've also worked with one of our partners to introduce a revolutionary approach to securing virtual workloads, one that is capable of scanning raw memory at the hypervisor layer to detect, protect and remediate against the most sophisticated attacks on an IT environment. This unique approach provides an effective line of defense against viruses, malware, ransomware and even root kit exploits. What's more, this advanced security technique complements security mechanisms already implemented to further strengthen protection of critical IT environments.

Providing a local caching mechanism within the XenServer hypervisor enables our virtual desktop customers to dramatically improve the performance of their virtual desktops, particularly during boot storms. By caching requests for OS image contents in local resources (i.e., memory and storage), XenServer is able to work with Provisioning Services to stream contents directly to virtual desktops, reducing resource utilization (network and CPU) while enhancing user productivity.

Expanded support for virtual graphics allows our customers to leverage their investments in hardware from the major graphics vendors and enable GPU-accelerated virtual desktops that effectively support graphics-intensive workloads.

Designing, developing and delivering features that bring out the best in virtualization technologies... that's our focus. And thanks to the invaluable insight and feedback provided by this community, will continue to be the driving force behind our innovation efforts.

Interested in evaluating the features described above, click here.

Until next time,

Andy

 

Continue reading
2514 Hits
0 Comments

Introduction to Saving VM Parameters: How I Metadata Backup

Introduction to Saving VM Parameters: How I Metadata Backup

XenServer Virtual Machines (VMs) certainly need no introduction, but even if you do not pardon the pun above, they still contain a lot of specialized and individualized information about their sizes, network connections, and myriad other settings that are generally not readily exposed, yet are integral to the operation and functionality of each VM. This blog entry is not intended to take a deep dive into the several hundred parameters that are defined for VMs, but rather just talk a bit about how to save, extract and potentially restore VM information based on them.

VM Metadata Backups

The purpose of backing up the metadata from a VM is to help you understand how it’s configured without having to search through the list of parameters accessible via various “xe” commands or XenAPI calls that require some programming efforts, plus also allow you to potentially track changes to your VMs without necessitating a full VM export/backup each time. You may not want or need to restore a VM from a full backup, but rather just revert a few parameters back to older values. You might also want to monitor what sorts of changes have taken place over time and equate those to performance or other metrics. In short, a number of reasons to maintain relatively frequent metadata backups of VMs can be justified.

Getting VM Metadata

There are a number of ways to obtain VM metadata settings. One of these is with the standard “xe” command to extract parameters, either individually, in a comma-separated string of multiple queries, or all of them such as with:

# xe vm-list uuid|name-label=UUID|NAME-LABEL params=all

Here, either the UUID or name-label can be used to select the VM.

Some parameters can also not only be obtained via “xe vm-param-get” but also changed, using the complementary “xe vm-param-set” operator. This gives you access to modifying around 30 parameters and reading over 80 of them.

The XenCenter console, xsconsole, provides a direct way to back up and restore VM metadata. From the "Backup, Restore and Update" menu, you can next navigate to the "Backup Virtual Machine Metadata" option and choose from available SRs onto which you wish to create a metadata backup of all available VMs. Note, though, that it will only evidently create metadata backups of running VMs! Likewise, the restore operation can only be performed on various subsets of VMs and not on an individual VM. Conversely, the metadata restore operation apparently can be applied to both running and halted VMs, but again cannot be performed on an individual VM.

Another option is to make use of the XenAPI library and extract tokens using XenAPI calls and access them for example using constructs such as these:

    vm_meta_status = gather_vm_meta(vm_object, full_backup_dir)

    vm_record = session.xenapi.VM.get_record(vm_object)

    vm_out = open ('%s/vm.cfg' % tmp_full_backup_dir, 'w')

    vm_out.write('name_label=%s\n' % vm_record['name_label'])

    vm_out.write('name_description=%s\n' % vm_record['name_description'])

    vm_out.write('memory_dynamic_max=%s\n' % vm_record['memory_dynamic_max'])

    vm_out.write('VCPUs_max=%s\n' % vm_record['VCPUs_max'])

    vm_out.write('VCPUs_at_startup=%s\n' % vm_record['VCPUs_at_startup'])

 

This can be time-consuming if you want to keep identifying and modifying code to deal with any additions or changes, plus you may periodically have to update your API libraries.

Yet another option is to make use of the not-well-documented features within the “xe” command set associated with vm-export and vm-import utilities. It is possible to export just the metadata from a VM using the following syntax:

# xe vm-export metadata=true uuid=UUID-OF-VM) filename=/full_path/OUTPUT_FILE.XVA

 

This will create what is in essence a tar file containing a single file that captures more than 300 parameters! The XML code has to be extracted from this tarball, which contains a single file that is always named ova.xml and can be pulled from the XVA files with a basic tar command in which specifying the file to extract as ova.xml is optional, since it’s the one and only file within the tar file:

 

# tar –xf OUTPUT_FULE.XVA

tar: ova.xml: implausibly old time stamp 1969-12-31 17:00:00

 

Note that you may get this rather interesting message regarding the timestamp, which can be ignored.  It may also turn out that the output file has absolutely no access permissions set, so you may want to run a “chmod 600 ova.xml” (or 644, etc.) to make it readable. You may also wish to rename it so it’s unambiguous and/or less likely to be overwritten.

For exported XVA files that are gzipped, you can extract the ova.xml file in a single operation with:

# tar xzf OUTPUT_FULE.XVA .gz

tar: ova.xml: implausibly old time stamp 1969-12-31 17:00:00

Once extracted, let’s take a look at the first part of the ova.xml file, which takes on a rather “ugly” appearance:

 

There is a wealth of information in here, but it’s not in a very friendly format. Fortunately, this can be readily rectified with the handy xmllint utility already present on XenServer (at least on 7.X):

# tar -xOf /ubuntu12-xs66-specialchars.XVA |  xmllint –format - >/tmp/output_VM.xml

The ”-O” flag causes the output to be redirected to stdout and hence it can be piped to the xmllint utility, which in turn can generate a very nicely formatted and properly indented XML file. Note that the “-“ before the redirection “>” operator signifies the output of xmllint to go to stdout and if desired, the command can be abbreviated as such, in which case the output will just appear on the terminal. It will be several hundred lines long, so you may as well redirect the output into a file where you can more conveniently deal with reviewing that amount of information.

Here is what the first part of the formatted file really looks like: 

 

OK, Great -- Now What?

Given the ability to now parse and peruse the XML metadata file associated with a particular VM, one could contemplate creating periodic backups of the VM metadata to have on hand in case one needs to reconstruct something or check if anything had changed. That’s all fine and good, but other than using “xe” commands or other means to change individual parameters, how does having these data help in the event of wanting to reconstruct or restore a VM?

The bottom line is that this feature has limited direct applications, though it does have a few. Consider the case of trying to use an XVA file that only contains the VM’s metadata to restore a VM. Note that the original VM must of course still exist or there will be nothing present to associate the VM storage with if a version of this VM cannot be found. However, if it is present, consider the following results:

# xe vm-import preserve=true filename=/ubuntu12-xs66-specialchars.XVA

The VM cannot be imported unforced because it is either the same version or an older version of an existing VM.

vm: 9538882a-c7e4-b8e5-c1f9-0d136f4a81b1 (TST-ubuntu12-vmtst3-xs66)

existing_version: 0

version_to_import: 0

 

Perhaps as anticipated, it will fail as the “preserve=true” flag will first check for a duplicate VM and upon discovering it, flags it as a command that would overwrite the existing VM. That’s a good thing. Leaving off that flag, we next try:

xe vm-import filename=/ubuntu12-xs66-specialchars.XVA metadata=true

This should yield success, but what kind of success? What happens is the VM created using the “metadata=true” flag produces a new VM copy with the same name, but a different UUID for the VM that is “Created by template provisioner.” What has happened is just that a fast clone has been created. You will see that if you delete such a VM created that way, it will not show any storage devices associated with it and in XenCenter, it will therefore not ask you if you want to delete the associated storage.

This is not entirely without use, however as you can still make use of this VM and perhaps even compare its characteristics to the original. Furthermore, you can export the VM, and import it as a new VM in which case it will gain the properties of a full clone. At that point, dependence on the original no longer exists.

This exercise might be useful in debugging or checking parameter-based performance or other issues between the original and subsequent metadata modifications. Such headers may also be useful just for tracking historical uses of VMs, checking to see what IP addresses may have been assigned, and numerous other things.

The Full XVA Export

The discussion up to this point should result in a mental lightbulb turning on and raising the question, well, if I restore a full export of a VM, isn’t all this information already in there? Since clearly it has to be for a vm-import to work properly, an examination of a full XVA export will indeed reveal that it consists of many fairly small files, numbering at times many thousands, but always starting with our old friend, ova.xml, as we see from this sample output that lists the contents instead of extracting it:

# tar -tvf  /exports/test-export.xva |less

---------- 0/0           29935 1969-12-31 17:00 ova.xml

---------- 0/0         1048576 1969-12-31 17:00 Ref:367/00000000

---------- 0/0              40 1969-12-31 17:00 Ref:367/00000000.checksum

---------- 0/0         1048576 1969-12-31 17:00 Ref:367/00000001

---------- 0/0              40 1969-12-31 17:00 Ref:367/00000001.checksum

---------- 0/0         1048576 1969-12-31 17:00 Ref:367/00000002

---------- 0/0              40 1969-12-31 17:00 Ref:367/00000002.checksum

---------- 0/0         1048576 1969-12-31 17:00 Ref:367/00000003

---------- 0/0              40 1969-12-31 17:00 Ref:367/00000003.checksum

---------- 0/0         1048576 1969-12-31 17:00 Ref:367/00000004

---------- 0/0              40 1969-12-31 17:00 Ref:367/00000004.checksum

etc.

The nice aspect of having the XVA file self-contained with all the metadata, as well as the data contents of the VM, makes this standalone file easy to move around and utilize as a backup.

The other nice aspect is that you, in fact, can use it as its own metadata storage mechanism and extract only that part of it if desired without needing to create a separate metadata backup (unless, of course, you want to do that more often and independently of a a vm-export). To extract just the metadata from this file shown above, all you need to do is to specify the embedded tar file name:

tar -xvf  /exports/test-export.xva ova.xml

We now have the same metadata file content we had when running the vm-export command combined with the “metadata=true” option.

In Summary

First off, it cannot be overstated that your XenServer environment should be backed up frequently and fastidiously, including both the pool metadata as well as the individual metadata for VMs. Even if you already have full exports of your VMs, having additional metadata can be useful for auditing purposes, as well as making it possible to check on parameters that are hard or impossible to glean through other means.

Nobody that I know was ever accused of creating too many backups.

Continue reading
3704 Hits
0 Comments

About XenServer

XenServer is the leading open source virtualization platform, powered by the Xen Project hypervisor and the XAPI toolstack. It is used in the world's largest clouds and enterprises.
 
Technical support for XenServer is available from Citrix.