Montag Feb 24, 2014

What's up with LDoms: Part 8 - Physical IO

Virtual IO SetupFinally finding some time to continue this blog series...  And starting the new year with a new chapter for which I hope to write several sections: Physical IO options for LDoms and what you can do with them.  In all previous sections, we talked about virtual IO and how to deal with it.  The diagram at the right shows the general architecture of such virtual IO configurations. However, there's much more to IO than that. 

From an architectural point of view, the primary task of the SPARC hypervisor is partitioning of  the system.  The hypervisor isn't usually very active - all it does is assign ownership of some parts of the hardware (CPU, memory, IO resources) to a domain, build a virtual machine from these components and finally start OpenBoot in that virtual machine.  After that, the hypervisor essentially steps aside.  Only if the IO components are virtual components, do we need hypervisor support.  But those IO components could also be physical.  Actually, that is the more "natural" option, if you like.  So lets revisit the creation of a domain:

We always start with assigning of CPU and memory in some very simple steps:

root@sun:~# ldm create mars
root@sun:~# ldm set-memory 8g mars
root@sun:~# ldm set-core 8 mars

If we now bound and started the domain, we would have OpenBoot running and we could connect using the virtual console.  Of course, since this domain doesn't have any IO devices, we couldn't yet do anything particularily useful with it.  Since we want to add physical IO devices, where are they?

To begin with, all physical components are owned by the primary domain.  This is the same for IO devices, just like it is for CPU and memory.  So just like we need to remove some CPU and memory from the primary domain in order to assign these to other domains, we will have to remove some IO from the primary if we want to assign it to another domain.  A general inventory of available IO resources can be obtained with the "ldm ls-io" command:

root@sun:~# ldm ls-io
NAME                                      TYPE   BUS      DOMAIN   STATUS  
----                                      ----   ---      ------   ------  
pci_0                                     BUS    pci_0    primary          
pci_1                                     BUS    pci_1    primary          
pci_2                                     BUS    pci_2    primary          
pci_3                                     BUS    pci_3    primary          
/SYS/MB/PCIE1                             PCIE   pci_0    primary  EMP     
/SYS/MB/SASHBA0                           PCIE   pci_0    primary  OCC
/SYS/MB/NET0                              PCIE   pci_0    primary  OCC     
/SYS/MB/PCIE5                             PCIE   pci_1    primary  EMP     
/SYS/MB/PCIE6                             PCIE   pci_1    primary  EMP     
/SYS/MB/PCIE7                             PCIE   pci_1    primary  EMP     
/SYS/MB/PCIE2                             PCIE   pci_2    primary  EMP     
/SYS/MB/PCIE3                             PCIE   pci_2    primary  OCC     
/SYS/MB/PCIE4                             PCIE   pci_2    primary  EMP     
/SYS/MB/PCIE8                             PCIE   pci_3    primary  EMP     
/SYS/MB/SASHBA1                           PCIE   pci_3    primary  OCC     
/SYS/MB/NET2                              PCIE   pci_3    primary  OCC     
/SYS/MB/NET0/IOVNET.PF0                   PF     pci_0    primary          
/SYS/MB/NET0/IOVNET.PF1                   PF     pci_0    primary          
/SYS/MB/NET2/IOVNET.PF0                   PF     pci_3    primary          
/SYS/MB/NET2/IOVNET.PF1                   PF     pci_3    primary

The output of this command will of course vary greatly, depending on the type of system you have.  The above example is from a T5-2.  As you can see, there are several types of IO resources.  Specifically, there are

  • BUS
    This is a whole PCI bus, which means everything controlled by a single PCI control unit, also called a PCI root complex.  It typically contains several PCI slots and possibly some end point devices like SAS or network controllers.
  • PCIE
    This is either a single PCIe slot.  In that case, it's name corresponds to the slot number you will find imprinted on the system chassis.  It is controlled by a root complex listed in the "BUS" column.  In the above example, you can see that some slots are empty, while others are occupied.  Or it is an endpoint device like a SAS HBA or network controller.  An example would be "/SYS/MB/SASHBA0" or "/SYS/MB/NET2".  Both of these typically control more than one actual device, so for example, SASHBA0 would control 4 internal disks and NET2 would control 2 internal network ports.
  • PF
    This is a SR-IOV Physical Function - usually an endpoint device like a network port which is capable of PCI virtualization.  We will cover SR-IOV in a later section of this blog.

All of these devices are available for assignment.  Right now, they are all owned by the primary domain.  We will now release some of them from the primary domain and assign them to a different domain.  Unfortunately, this is not a dynamic operation, so we will have to reboot the control domain (more precisely, the affected domains) once to complete this.

root@sun:~# ldm start-reconf primary
root@sun:~# ldm rm-io pci_3 primary
root@sun:~# reboot
[ wait for the system to come back up ]
root@sun:~# ldm add-io pci_3 mars
root@sun:~# ldm bind mars

With the removal of pci_3, we also removed PCIE8, SYSBHA1 and NET1 from the primary domain and added all three to mars.  Mars will now have direct, exclusive access to all the disks controlled by SASHBA1, all the network ports on NET1 and whatever we chose to install in PCIe slot 8.  Since in this particular example, mars has access to internal disk and network, it can boot and communicate using these internal devices.  It does not depend on the primary domain for any of this.  Once started, we could actually shut down the primary domain.  (Note that the primary is usually the home of vntsd, the console service.  While we don't need this for running or rebooting mars, we do need it in case mars falls back to OBP or single-user.) 

Root Domain SetupMars now owns its own PCIe root complex.  Because of this, we call mars a root domain.  The diagram on the right shows the general architecture.  Compare this to the diagram above!  Root domains are truely independent partitions of a SPARC system, very similar in functionality to Dynamic System Domains in the E10k, E25k or M9000 times (or Physical Domains, as they're now called).  They own their own CPU, memory and physical IO.   They can be booted, run and rebooted independently of any other domain.  Any failure in another domain does not affect them.  Of course, we have plenty of shared components: A root domain might share a mainboard, a part of a CPU (mars, for example, only has 2 cores...), some memory modules, etc. with other domains.  Any failure in a shared component will of course affect all the domains sharing that component, which is different in Physical Domains because there are significantly fewer shared components.  But beyond this, root domains have a level of isolation very similar to that of Physical Domains.

Comparing root domains (which are the most general form of physical IO in LDoms) with virtual IO, here are some pros and cons:

Pros:

  • Root domains are fully independet of all other domains (with the exception of console access, but this is a minor limitation).
  • Root domains have zero overhead in IO - they have no virtualization overhead whatsoever.
  • Root domains, because they don't use virtual IO, are not limited to disk and network, but can also attach to tape, tape libraries or any other, generic IO device supported in their PCIe slots.

Cons:

  • Root domains are limited in number.  You can only create as many root domains as you have PCIe root complexes available.  In current T5 and M5/6 systems, that's two per CPU socket.
  • Root domains can not live migrate.  Because they own real IO hardware (with all these nasty little buffers, registers and FIFOs), they can not be live migrated to another chassis.

Because of these different characteristics, root domains are typically used for applications that tend to be more static, have higher IO requirements and/or larger CPU and memory footprints.  Domains with virtual IO, on the other hand, are typically used for the mass of smaller applications with lower IO requirements.  Note that "higher" and "lower" are relative terms - LDoms virtual IO is quite powerful.

This is the end of the first part of the physical IO section, I'll cover some additional options next time.  Here are some links for further reading:

Donnerstag Jul 04, 2013

What's up with LDoms: Part 7 - Layered Virtual Networking

Back for another article about LDoms - today we'll cover some tricky networking options that come up if you want to run Solaris 11 zones in LDom guest systems.  So what's the problem?

MAC Tables in an LDom systemLet's look at what happens with MAC addresses when you create a guest system with a single vnet network device.  By default, the LDoms Manager selects a MAC address for the new vnet device.  This MAC address is managed in the vswitch, and ethernet packets from and to that MAC address can flow between the vnet device, the vswitch and the outside world.  The ethernet switch on the outside will learn about this new MAC address, too.  Of course, if you assign a MAC address manually, this works the same way.  This situation is shown in the diagram at the right.  The important thing to note here is that the vnet device in the guest system will have exactly one MAC address, and no "spare slots" with additional addresses. 

Add zones into the picture.  With Solaris 10, the situation is simple.  The default behaviour will be a "shared IP" zone, where traffic from the non-global zone will use the IP (and thus ethernet) stack from the global zone.  No additional MAC addresses required.  Since you don't have further "physical" interfaces, there's no temptation to use "exclusive IP" for that zone, except if you'd use a tagged VLAN interface.  But again, this wouldn't need another MAC address.


MAC Tables in previous versionsWith Solaris 11, this changes fundamentally.  Solaris 11, by default, will create a so called "anet" device for any new zone.  This device is created using the new Solaris 11 network stack, and is simply a virtual NIC.  As such, it will have a MAC address.  The default behaviour is to generate a random MAC address.  However, this random MAC address will not be known to the vswitch in the IO domain and to the vnet device in the global zone, and starting such a zone will fail.


MAC Tables in version 3.0.0.2The solution is to allow the vnet device of the LDoms guest to provide more than one MAC address, similar to typical physical NICs which have support for numerous MAC addresses in "slots" that they manage.  This feature has been added to Oracle VM Server for SPARC in version 3.0.0.2.  Jeff Savit wrote about it in his blog, showing a nice example of how things fail without this feature, and how they work with it.  Of course, the same solution will also work if your global zone uses vnics for purposes other than zones.

To make this work, you need to do two things:

  1. Configure the vnet device to have more than one MAC address.  This is done using the new option "alt-mac-addrs" with either ldm add-vnet or ldm set-vnet.  You can either provide manually selected MAC addresses here, or rely on LDoms Manager to use it's MAC address selection algorithm to provide one.
  2. Configure the zone to use the "auto" option instead of "random" for selecting a MAC address.  This will cause the zone to query the NIC for available MAC addresses instead of coming up with one and making the NIC accept it.

I will not go into the details of how this is configured, as this is very nicely covered by Jeff's blog entry already.  I do want to add that you might see similar issues with layered virtual networking in other virtualization solutions:  Running Solaris 11 vnics or zones with exclusive IP in VirtualBox, OVM x86 or VMware will show the very same behaviour.   I don't know if/when these thechnologies will provide a solution similar to what we now have with LDoms.

Montag Jan 14, 2013

LDoms IO Best Practices & T4 Red Crypto Stack

In November, I presented at DOAG Konferenz & Ausstellung 2012.  Now, almost two months later, I finally get around to posting the slides here...

  • In "LDoms IO Best Practices" I discuss different IO options for both disk and networking and give some recommens on how you to choose the right ones for your environment.  A couple hints about performance are also included.

I hope the slides are useful!

Freitag Dez 21, 2012

What's up with LDoms: Part 6 - Sizing the IO Domain

Before Christmas break, let's look at a topic that's one of the more frequently asked questions: Sizing of the Control Domain and IO Domain.

By now, we've seen how to create the basic setup, create a simple domain and configure networking and disk IO.  We know that for typical virtual IO, we use vswitches and virtual disk services to provide virtual network and disk services to the guests.  The question to address here is: How much CPU and memory is required in the Control and IO-domain (or in any additional IO domain) to provide these services without being a bottleneck?

The answer to this question can be very quick: LDoms Engineering usually recommends 1 or 2 cores for the Control Domain.

However, as always, one size doesn't fit all, and I'd like to look a little closer. 

Essentially, this is a sizing question just like any other system sizing.  So the first question to ask is: What services is the Control Domain providing that need CPU or memory resources?  We can then continue to estimate or measure exactly how much of each we will need. 

As for the services, the answer is straight forward: 

  • The Control Domain usually provides
    • Console Services using vntsd
    • Dynamic Reconfiguration and other infrastructure services
    • Live Migration
  • Any IO Domain (either the Control Domain or an additional IO domain) provides
    • Disk Services configured through the vds
    • Network Services configured through the vswitch

For sizing, it is safe to assume that vntsd, ldmd (the actual LDoms Manager daemon), ldmad (the LDoms agent) and any other infrastructure tasks will require very little CPU and can be ignored.  Let's look at the remaining three services:

  • Disk Services
    Disk Services have two parts:  Data transfer from the IO domain to the backend devices and data transfer from the IO Domain to the guest.  Disk IO in the IO domain is relatively cheap, you don't need many CPU cycles to deal with it.  I have found 1-2 threads of a T2 CPU to be sufficient for about 15.000 IOPS.  Today we usually use T4...
    However, this also depends on the type of backend storage you use.  FC or SAS rawdevice LUNs will have very little CPU overhead.  OTOH, if you use files hosted on NFS or ZFS, you are likely to see more CPU activity involved.  Here, your mileage will vary, depending on the configuration and usage pattern.  Also keep in mind that backends hosted on NFS or iSCSI also involve network traffic.
  • Network Services - vswitches
    There is a very old sizing rule that says that you need 1 GHz worth of CPU to saturate 1GBit worth of ethernet.  SAE has published a network encryption benchmark where a single T4 CPU at 2.85 GHz will transmit around 9 GBit at 20% utilization.  Converted into strands and cores, that would mean about 13 strands - less than 2 cores for 9GBit worth of traffic.  Encrypted, mind you.  Applying the mentioned old rule to this result, we would need just over 3 cores at 2.85 GHz to do 9 GBit - it seems we've made some progress in efficiency ;-)
    Applying all of this to IO Domain sizing, I would consider 2 cores an upper bound for typical installations, where you might very well get along with just one core, especially on smaller systems like the T4-1, where you're not likely to have several guest systems that each require  10GBit wirespeed networking.
  • Live Migration
    When considering Live Migration, we should understand that the Control Domains of the two involved systems are the ones actually doing all the work.  They encrypt, compress and send the source system's memory to the target system.  For this, they need quite a bit of CPU.  Of course, one could argue that Live Migration is something happening in the background, so it doesn't matter how fast it's actually done.  However, there's still the suspend-phase, where the guest system is suspended and the remaining dirty memory pages copied over to the other side.  This phase, while typically very very short, significantly impacts the "live" experience of Live Migration.  And while other factors like guest activity level and memory size also play a role, there's also a direct connection between CPU power and the length of this suspend time.  The relation between Control Domain CPU configuration and suspend time has been studied and published in a Whitepaper "Increasing Application Availability Using Oracle VM Server for SPARC (LDoms) An Oracle Database Example".  The conclusion: For minimum suspend times, configure 3 cores in the Control Domain.  I personally have made good experience with 2 cores, measuring suspend times as low as 0.1 second with a very idle domain, so again, your mileage will vary.

    Another thought here:  The Control Domain doesn't usually do Live Migration on a permanent basis.  So if a single core is sufficient for the IO Domain role of the Control Domain, you are in good shape for everyday business with just one core.  When you need additional CPU for a quick Live Migration, why not borrow it from somewhere else, like the domain being migrated, or any other domain not currently very busy?  CPU DR does lend itself for this purpose...

As you've seen, there are some rules, there is some experience, but still, there isn't the single, one answer.  In many cases, you should be ok with a single core on T4 for each IO domain.  If you use Live Migration a lot, you might want to add another core to the Control Domain.  On larger systems with higher networking demands, two cores for each IO Domain might be right.  If these recommendations are good enough for you, you're done.  If you want to dig deeper, simply check what's really going on in your IO Domains.  Use mpstat (1M) to study the utilization of your IO Domain's CPUs in times of high activity.  Perhaps record CPU utilization over a period of time, using your tool of choice.  (I recommend DimSTAT for that.)  With these results, you should be able to adjust the amount of CPU resources of your IO Domains to your exact needs.  However, when doing that, please remember those unannounced utilization peaks - don't be too stingy.  Saving one or two CPU strands won't buy you too much, all things considered.

A few words about memory:  This is much more straight forward.  If you're not using ZFS as a backing store for your virtual disks, you should be well in the green with 2-4GB of RAM.  My current test system, running Solaris 11.0 in the Control Domain, needs less than 600 MB of virtual memory.  Remember that 1GB is the supported minimum for Solaris 11 (and it's changed to 1.5 GB for Solaris 11.1). If you do use ZFS, you might want to reserve a couple GB for its ARC, so perhaps 8 GB are more appropriate.  On the Control Domain, which is the first domain to be bound, take 7680MB, which add up to 8GB together with the hypervisor's own 512MB, nicely fitting the 8GB boundary favoured by the memory controllers.  Again, if you want to be precise, monitor memory usage in your IO domains.

Links:

Update: I just learned that the hypervisor doesn't always take exactly 512MB. So if you do want to align with the 8GB boundary, check the sizes using "ldm ls-devices -a mem". Everything bound to "sys" is owned by the hypervisor.

Mittwoch Nov 07, 2012

What's up with LDoms: Part 5 - A few Words about Consoles

Back again to look at a detail of LDom configuration that is often forgotten - the virtual console server.

Remember, LDoms are SPARC systems.  As such, each guest will have it's own OBP running.  And to connect to that OBP, the administrator will need a console connection.  Since it's OBP, and not some x86 BIOS, this console will be very serial in nature ;-)  It's really very much like in the good old days, where we had a terminal concentrator where all those serial cables ended up in.  Just like with other components in LDoms, the virtualized solution looks very similar.

Every LDom guest requires exactly one console connection.  Envision this similar to the RS-232 port on older SPARC systems.  The LDom framework provides one or more console services that provide access to these connections.  This would be the virtual equivalent of a network terminal server (NTS), where all those serial cables are plugged in.  In the physical world, we'd have a list somewhere, that would tell us which TCP-Port of the NTS was connected to which server.  "ldm list" does just that:

root@sun # ldm list
NAME             STATE      FLAGS   CONS    VCPU  MEMORY   UTIL  UPTIME
primary          active     -n-cv-  UART    16    7680M    0.4%  27d 8h 22m
jupiter          bound      ------  5002    20    8G             
mars             active     -n----  5000    2     8G       0.5%  55d 14h 10m
venus            active     -n----  5001    2     8G       0.5%  56d 40m
pluto            inactive   ------          4     4G             

The column marked "CONS" tells us, where to reach the console of each domain. In the case of the primary domain, this is actually a (more) physical connection - it's the console connection of the physical system, which is either reachable via the ILOM of that system, or directly via the serial console port on the chassis. All the other guests are reachable through the console service which we created during the inital setup of the system.  Note that pluto does not have a port assigned.  This is because pluto is not yet bound.  (Binding can be viewed very much as the assembly of computer parts - CPU, Memory, disks, network adapters and a serial console cable are all put together when binding the domain.)  Unless we set the port number explicitly, LDoms Manager will do this on a first come, first serve basis.  For just a few domains, this is fine.  For larger deployments, it might be a good idea to assign these port numbers manually using the "ldm set-vcons" command.  However, there is even better magic associated with virtual consoles.

You can group several domains into one console group, reachable through one TCP port of the console service.  This can be useful when several groups of administrators are to be given access to different domains, or for other grouping reasons.  Here's an example:

root@sun # ldm set-vcons group=planets service=console jupiter
root@sun # ldm set-vcons group=planets service=console pluto
root@sun # ldm bind jupiter 
root@sun # ldm bind pluto
root@sun # ldm list
NAME             STATE      FLAGS   CONS    VCPU  MEMORY   UTIL  UPTIME
primary          active     -n-cv-  UART    16    7680M    6.1%  27d 8h 24m
jupiter          bound      ------  5002    200   8G             
mars             active     -n----  5000    2     8G       0.6%  55d 14h 12m
pluto            bound      ------  5002    4     4G             
venus            active     -n----  5001    2     8G       0.5%  56d 42m

root@sun # telnet localhost 5002
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

sun-vnts-planets: h, l, c{id}, n{name}, q:l
DOMAIN ID           DOMAIN NAME                   DOMAIN STATE             
2                   jupiter                       online                   
3                   pluto                         online                   

sun-vnts-planets: h, l, c{id}, n{name}, q:npluto
Connecting to console "pluto" in group "planets" ....
Press ~? for control options ..

What I did here was add the two domains pluto and jupiter to a new console group called "planets" on the service "console" running in the primary domain.  Simply using a group name will create such a group, if it doesn't already exist.  By default, each domain has its own group, using the domain name as the group name.  The group will be available on port 5002, chosen by LDoms Manager because I didn't specify it.  If I connect to that console group, I will now first be prompted to choose the domain I want to connect to from a little menu.

Finally, here's an example how to assign port numbers explicitly:

root@sun # ldm set-vcons port=5044 group=pluto service=console pluto
root@sun # ldm bind pluto
root@sun # ldm list
NAME             STATE      FLAGS   CONS    VCPU  MEMORY   UTIL  UPTIME
primary          active     -n-cv-  UART    16    7680M    3.8%  27d 8h 54m
jupiter          active     -t----  5002    200   8G       0.5%  30m
mars             active     -n----  5000    2     8G       0.6%  55d 14h 43m
pluto            bound      ------  5044    4     4G             
venus            active     -n----  5001    2     8G       0.4%  56d 1h 13m

With this, pluto would always be reachable on port 5044 in its own exclusive console group, no matter in which order other domains are bound.

Now, you might be wondering why we always have to mention the console service name, "console" in all the examples here.  The simple answer is because there could be more than one such console service.  For all "normal" use, a single console service is absolutely sufficient.  But the system is flexible enough to allow more than that single one, should you need them.  In fact, you could even configure such a console service on a domain other than the primary (or control domain), which would make that domain a real console server.  I actually have a customer who does just that - they want to separate console access from the control domain functionality.  But this is definately a rather sophisticated setup.

Something I don't want to go into in this post is access control.  vntsd, which is the daemon providing all these console services, is fully RBAC-aware, and you can configure authorizations for individual users to connect to console groups or individual domain's consoles.  If you can't wait until I get around to security, check out the man page of vntsd.

Further reading:

  • The Admin Guide is rather reserved on this subject.  I do recommend to check out the Reference Manual.
  • The manpage for vntsd will discuss all the control sequences as well as the grouping and authorizations mentioned here.

Montag Sep 10, 2012

Secure Deployment of Oracle VM Server for SPARC - updated

Quite a while ago, I published a paper with recommendations for a secure deployment of LDoms.  Many things happend in the mean time, and an update to that paper was due.  Besides some minor spelling corrections, many obsolete or changed links were updated.  However, the main reason for the update was the introduction of a second usage model for LDoms.  In a very short few words: With the success especially of the T4-4, many deployments make use of the hardware partitioning capabilities of that platform, assigning full PCIe root complexes to domains, mimicking dynamic system domains if you will.  This different way of using the hypervisor needed to be addressed in the paper.  You can find the updated version here:

Secure Deployment of Oracle VM Server for SPARC
Second Edition

I hope it'll be useful!

Freitag Jul 13, 2012

What's up with LDoms: Part 3 - A closer look at Disk Backend Choices

In this section, we'll have a closer look at virtual disk backends and the various choises available here.  As a little reminder, a disk backend, in LDoms speak, is the physical storage used when creating a virtual disk for a guest system.  In other virtualization solutions, these are sometimes called virtual disk images, a term that doesn't really fit for all possible options available in LDoms.

In the previous example, we used a ZFS volume as a backend for the boot disk of mars.  But there are many other ways to store the data of virtual disks.  The relevant section in the Admin Guide lists all the available options:

  • Physical LUNs, in any variant that the Control Domain supports.  This of course includes SAN, iSCSI and SAS, including the internal disks of the host system.
  • Logical Volumes like ZFS Volumes, but also SVM or VxVM
  • Regular Files. These can be stored in any filesystem, as long as they're accessible by the LDoms subsystem. This includes storage on NFS.

Each of these backend devices have their own set of characteristica that should be considered when deciding which backend type to use.  Let's look at them in a little more detail.

LUNs are the most generic option. By assigning a virtual disk to a LUN backend, the guest essentially gains full access to the underlying storage device, whatever that might be.  It will see the volume label of the LUN, it can see and alter the partition table of the LUN, it can also read or set SCSI reservations on that device.  Depending on the way the LUN is connected to the host system, this very same LUN could also be attached to a second host and a guest residing on it, with the two guests sharing the data on that one LUN, or supporting live migration.  If there is a filesystem on the LUN, the guest will be able to mount that filesystem, just like any other system with access to that LUN, be it virtualized or direct.  Bear in mind that most filesystems are non-shared filesystems.  This doesn't change here, either.  For the IO domain (that's the domain where the physical LUN is connected) LUNs mean the least possible amount of work.  All it has to do is pass data blocks up and down to and from the LUN, there is a very minimum of driver layers invovled.

Flat files, on the other hand, are the most simple option, very similar in user experience to what one would do in a desktop hypervisor like VirtualBox.  The easiest way to create one is with the "mkfile" command.  For the guest, there is no real difference to LUNs.  The virtual disk will, just like in the LUN case, appear to be a full disk, partition table, label and all.  Of course, initially, it'll be all empty, so the first thing the guest usually needs to do is write a label to the disk.  The main difference to LUNs is in the way these image files are managed.  Since they are files in a filesystem, they can be copied, moved and deleted, all of which should be done with care, especially if the guest is still running.  They can be managed by the filesystem, which means attributes like compression, encryption or deduplication in ZFS could apply to them - fully transparent to the guest.  If the filesystem is a shared filesystem like NFS or SAM-FS, the file (and thus the disk image) could be shared by another LDom on another system, for example as a shared database disk or for live migration.  Their performance will be impacted by the filesystem, too.  The IO domain might cache some of the file, hoping to speed operations.  If there are many such image files on a single filesystem, they might impact each other's performance.  These files, by the way, need not be empty initially.  A typical use case would be a Solaris iso image file.  Adding it to a guest as a virtual disk will allow that guest to boot (and install) off that iso image as if it were a physical CD drive.

Finally, there are logical Volumes, typically created with volume managers such as Solaris Volume Manager (SVM) or Veritas Volume Manager (VxVM) or ZFS, of course.  For the guest, again, these look just like ordinary disks, very much like files.  The difference to files is in the management layer;  The logical volumes are created straigt from the underlying storage, without a filesystem layer in between.  In the database world, we would call these "raw devices", and their device names in Solaris are very similar to those of physical LUNs.  We need different commands to find out how large these volumes are, or how much space is left on the storage devices underneath.  Other than that, however, they are very similar to files in many ways.  Sharing them between two host systems is likely to be more complex, as one would need the corresponding cluster volume managers, which typically only really work in combination with Solaris Cluster.  One type of volume that deserves special mentioning is the ZFS Volume.  It offers all the features of a normal ZFS dataset: Clones, snapshots, compression, encryption, deduplication, etc.  Especially with snapshots and clones, they lend themselves as the ideal backend for all use cases that make heavy use of these features. 

For the sake of completeness, I'd like to mention that you can export all of these backends to a guest with or without the "slice" option, something that I consider less usefull in most cases, which is why I'd like to refer you to the relevant section in the admin guide if you want to know more about this.

Lastly, you do have the option to export these backends read-only to prevent any changes from the guests.  Keep in mind that even mounting a UFS filesystem read only would require a write operation to the virtual disk.  The most typical usecase for this is probably an iso-image, which can indeed be mounted read-only.  You can also export one backend to more than one guest.  In the physical world, this would correspond to using the same SAN LUN on several hosts, and the same restrictions with regards to shared filesystems etc. apply.

So now that we know about all these different options, when should we use which kind of backend ?  The answer, as usual, is: It depends!

LUNs require a SAN (or iSCSI) infrastructure which we tend to associate with higher cost.  On the other hand, they can be shared between many hosts, are easily mapped from host to host and bring a rich feature set of storage management and redundancy with them.  I recommend LUNs (especially SAN) for both boot devices and data disks of guest systems in production environments.  My main reasons for this are:

  • They are very light-weight on the IO domain
  • They avoid any double buffering of data in the guest and in the IO domain because there is no filesystem layer involved in the IO domain.
  • Redundancy for the device and the data path is easy
  • They allow sharing between hosts, which in turn allows cluster implementations and live migration
  • All ZFS features can be implemented in the guest, if desired.

For test and development, my first choice is usually the ZFS volume.  Unlike VxVM, it comes free of charge, and it's features like snapshots and clones meet the typical requirements of such environments to quickly create, copy and destroy test environments.  I explicitly recommend against using ZFS snapshots/clones (files or volumes) over a longer period of time.  Since ZFS records the delta between the original image and the clones, the space overhead will eventually grow to a multiple of the initial size and eventually even prevent further IO to the virtual disk if the zpool is full.  Also keep in mind that ZFS is not a shared filesystem.  This prevents guest that use ZFS files or volumes as virtual disks from doing live migration.  Which leads directly to the recommendation for files:

I recommend files on NFS (or other shared filesystems) in all those cases where SAN LUNs are not available but shared access to disk images is required because of live migration (or because of cluster software like Solaris Cluster or RAC is running in the guests).  The functionality is mostly the same as for LUNs, with the exception of SCSI reservations, which don't work with a file backend.  However, CPU requirements in the IO domain and performance of NFS files as compared to SAN LUNs is likely to be different, which is why I strongly recommend to use SAN LUNs for all prodution use cases.

Further reading:

Freitag Jun 29, 2012

Oracle VM Server for SPARC Demo Videos

I just stumbled across several well done demos for newer LDoms features.  Find them all in the youtube channel "Oracle VM Server for SPARC".  I'd like to recommend the ones about power management and cross CPU migration specifically :-)

Donnerstag Mai 24, 2012

OVM Server for SPARC 2.2 released!

The long awaited new version 2.2 of Oracle VM Server for SPARC has been released!  Without repeating all the things mentioned elsewhere, here the main points:

There's a good summary at the Oracle Virtualization Blog. And of course, there's the official documentation:

Happy virtualizing!

Donnerstag Jun 09, 2011

OVM Server for SPARC 2.1 is here!

The newest version of OVM Server for SPARC aka LDoms is released!  Here's the press release...


What, already a new version again?  Well, the most missed feature in the previous versions was finally completed, and we didn't want to keep everyone waiting ;-)  The new version 2.1 turns "Warm Migration" into "Live Migration".  All the other improvements can be found in "What's New".  Once I have further details about Live Migration, I'll post them here.  You can find the download on MOS and the documentation on OTN.

About

Neuigkeiten, Tipps und Wissenswertes rund um SPARC, CMT, Performance und ihre Analyse sowie Erfahrungen mit Solaris auf dem Server und dem Laptop.

This is a bilingual blog (most of the time). Please select your prefered language:
.
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today