This discussion is archived
1 2 Previous Next 22 Replies Latest reply: Mar 15, 2012 3:12 AM by Avi Miller Go to original post RSS
  • 15. Re: hard partitioning and hyperthreading and licensing and confusion
    user386688 Newbie
    Currently Being Moderated
    Avi Miller wrote:
    Julian Mccoy-Daly wrote:
    "Hard partitioning is the ONLY case where you are allowed to modify the virtual machine configuration file manually. For all other changes to a virtual machine, use the Oracle VM Manager user interface."
    Correct.
    And the implication here is that it is modifying the vm.cfg to add the pin statement, not to add repositories that are manually created with the VirtualMachines/VMUUID/vm.cfg that is then modified to point back to the vm image in a different repository.
    Why would you need to do this? You can select which repository is used to store the configuration file on the first step of the Create VM wizard. Just select the repository that's only presented to the subset of servers. No manual modifications required at all.
    That would be because, to use OVM 3, we would be migrating something like 120 machines from OVM 2 clusters
  • 16. Re: hard partitioning and hyperthreading and licensing and confusion
    Avi Miller Guru
    Currently Being Moderated
    Julian Mccoy-Daly wrote:
    That would be because, to use OVM 3, we would be migrating something like 120 machines from OVM 2 clusters
    There is a process and script available from My Oracle Support that will migrate the guests from OVM2 to OVM3 for you. You just need to setup a new OVM3 cluster.
  • 17. Re: hard partitioning and hyperthreading and licensing and confusion
    user386688 Newbie
    Currently Being Moderated
    Avi Miller wrote:
    Julian Mccoy-Daly wrote:
    That would be because, to use OVM 3, we would be migrating something like 120 machines from OVM 2 clusters
    There is a process and script available from My Oracle Support that will migrate the guests from OVM2 to OVM3 for you. You just need to setup a new OVM3 cluster.
    Indeed there is. And after running it, you will then want to distribute the VMs that can no longer be subject to a manual placement policy to a different repository for licensing purposes - which will mean manual revision of the vm.cfg file, since it quotes absolute paths and the repository uuid will obviously be incorrect.

    Or maybe one should move machines due to be on a separate ovm3 repository to a new ovm2 repository prior to the migration of the original so the migration can then be performed in two steps...
  • 18. Re: hard partitioning and hyperthreading and licensing and confusion
    Avi Miller Guru
    Currently Being Moderated
    Julian Mccoy-Daly wrote:
    Indeed there is. And after running it, you will then want to distribute the VMs that can no longer be subject to a manual placement policy to a different repository for licensing purposes - which will mean manual revision of the vm.cfg file, since it quotes absolute paths and the repository uuid will obviously be incorrect.
    There is a Move option for VMs in the UI. Well, there definitely is in the 3.1 version which will be released later this year, and I believe there is one in 3.0.3 as well. Means you can move the vm.cfg from one repository to another. At worst, you can clone from one repository to another and then delete the original. All of this is possible using the UI without manually editing the vm.cfg.

    Not sure if you can target a specific repository with the migration script, but that may also be an option. Keep in mind that only the vm.cfg has to sit on the repository that is presented to a subset of servers, not the virtual disks as well. So no actual editing of the vm.cfg is ever required. The vm.cfg is required to boot the VM, so if it's only presented to X out of Y servers, that VM can only boot/migrate to those servers as well.
    Or maybe one should move machines due to be on a separate ovm3 repository to a new ovm2 repository prior to the migration of the original so the migration can then be performed in two steps...
    Possibly. There are many ways to achieve what you want.
  • 19. Re: hard partitioning and hyperthreading and licensing and confusion
    user386688 Newbie
    Currently Being Moderated
    Would the "move" option be the "migrate option"? As I only have one ovm server in my ovm3 pool, the only option would be to move a machine to the "unnassigned virtual machines folder". Would that show more pools/servers as choices if there were more?

    On the topic of licensing, if one was to present a repository to, for example, a subset of two OVM servers, or a different pool with two OVM servers, would the position be that, if they were run on one machine normally but allowed to run on the second in case of failure of the first, that one would only have to license the processors pinned to on the first server? And the second only if run for over 10 days over one calendar year on that box? Or would the position be that both ,achines required licensing?

    Cheers

    Julian
  • 20. Re: hard partitioning and hyperthreading and licensing and confusion
    Avi Miller Guru
    Currently Being Moderated
    Julian Mccoy-Daly wrote:
    Would the "move" option be the "migrate option"? As I only have one ovm server in my ovm3 pool, the only option would be to move a machine to the "unnassigned virtual machines folder". Would that show more pools/servers as choices if there were more?
    In OVM 3.1, I have a "Move or Clone" option, which either moves the configuration file and/or disks of the VM from one storage repository to another or clones/copies them to the same or a different repository. I just checked 3.0.3, and it only has the Clone option, so the Move option must be new in 3.1.

    However, something that does work (which I just tested) is simply moving the UUID named folder containing the vm.cfg from one repository to another and then refreshing both repositories.

    So, assuming you had the following output from df -h:
    /dev/mapper/360014057aa3bd34deee5d4c82dbbb3de
                          250G   30G  221G  12% /OVS/Repositories/0004fb0000030000de5272314a98b06c
    nfsserver:/ovs3repo
                          5.4T  3.4T  2.1T  62% /OVS/Repositories/0004fb00000300008e6ab7e84ec585a7
    You can see I have two repositories, one iSCSI and one NFS. If I look in the VirtualMachines folder in each, I'll see directories named after the UUID of each VM. So, if you move a directory from /OVS/Repositories/0004fb0000030000de5272314a98b06c/VirtualMachines to /OVS/Repositories/0004fb00000300008e6ab7e84ec585a7/VirtualMachines and then trigger a refresh from the UI for both repositories, you'll see the VM jump from one repository to the other. Nifty, huh?
    On the topic of licensing, if one was to present a repository to, for example, a subset of two OVM servers, or a different pool with two OVM servers, would the position be that, if they were run on one machine normally but allowed to run on the second in case of failure of the first, that one would only have to license the processors pinned to on the first server? And the second only if run for over 10 days over one calendar year on that box? Or would the position be that both ,achines required licensing?
    It would follow the standard licensing, so as long as it only ran on the first server and less than 10 days over one calendar year on the second, you'd be OK.
  • 21. Re: hard partitioning and hyperthreading and licensing and confusion
    user386688 Newbie
    Currently Being Moderated
    Avi Miller wrote:
    Julian Mccoy-Daly wrote:
    Would the "move" option be the "migrate option"? As I only have one ovm server in my ovm3 pool, the only option would be to move a machine to the "unnassigned virtual machines folder". Would that show more pools/servers as choices if there were more?
    In OVM 3.1, I have a "Move or Clone" option, which either moves the configuration file and/or disks of the VM from one storage repository to another or clones/copies them to the same or a different repository. I just checked 3.0.3, and it only has the Clone option, so the Move option must be new in 3.1.

    However, something that does work (which I just tested) is simply moving the UUID named folder containing the vm.cfg from one repository to another and then refreshing both repositories.

    So, assuming you had the following output from df -h:
    /dev/mapper/360014057aa3bd34deee5d4c82dbbb3de
    250G   30G  221G  12% /OVS/Repositories/0004fb0000030000de5272314a98b06c
    nfsserver:/ovs3repo
    5.4T  3.4T  2.1T  62% /OVS/Repositories/0004fb00000300008e6ab7e84ec585a7
    You can see I have two repositories, one iSCSI and one NFS. If I look in the VirtualMachines folder in each, I'll see directories named after the UUID of each VM. So, if you move a directory from /OVS/Repositories/0004fb0000030000de5272314a98b06c/VirtualMachines to /OVS/Repositories/0004fb00000300008e6ab7e84ec585a7/VirtualMachines and then trigger a refresh from the UI for both repositories, you'll see the VM jump from one repository to the other. Nifty, huh?
    On the topic of licensing, if one was to present a repository to, for example, a subset of two OVM servers, or a different pool with two OVM servers, would the position be that, if they were run on one machine normally but allowed to run on the second in case of failure of the first, that one would only have to license the processors pinned to on the first server? And the second only if run for over 10 days over one calendar year on that box? Or would the position be that both ,achines required licensing?
    It would follow the standard licensing, so as long as it only ran on the first server and less than 10 days over one calendar year on the second, you'd be OK.
    Move = cool :)

    On the subject of moving just the VM uuid directory containing the config file - yup ok I know that would work, but it's kind of messy. My overly orderly mind would want me to have the image file in the same repository as the config file... never mind, I'll get over it. In time.

    Back to the licensing, a topic near to my heart at the moment, if you were to present another repository to a subset of, say, two servers - one of which you would deem licensed for technology licensed products, how would you ensure that the VM only came up on your licensed box? Or would it be a case of present to only one server? This is getting clearer, but OVM 3 could use a set of controls suited to licensing and HA capability. IMO of course.

    Thanks for your help :)
  • 22. Re: hard partitioning and hyperthreading and licensing and confusion
    Avi Miller Guru
    Currently Being Moderated
    Julian Mccoy-Daly wrote:
    On the subject of moving just the VM uuid directory containing the config file - yup ok I know that would work, but it's kind of messy. My overly orderly mind would want me to have the image file in the same repository as the config file... never mind, I'll get over it. In time.
    Actually, OVM3 was designed for exactly this scenario: you can put your configuration/OS disks on cheap, slow NFS storage, while your virtual disk images sit on fast, expensive, FC SAN (or ZFSSA or whatever).
    Back to the licensing, a topic near to my heart at the moment, if you were to present another repository to a subset of, say, two servers - one of which you would deem licensed for technology licensed products, how would you ensure that the VM only came up on your licensed box? Or would it be a case of present to only one server? This is getting clearer, but OVM 3 could use a set of controls suited to licensing and HA capability. IMO of course.
    Oracle doesn't provide any technical license controls, AFAIK. As for how you would ensure this, my advice is to talk to your Oracle Sales Representative, who in turn would ask Oracle Licensing, who are the final word on this subject. :) I know Oracle Licensing deems the Preferred Server Placement mechanism of OVM2 sufficient for licensing purposes, so I can only hope they would accept a repository presented to a subset of servers in similar fashion.
1 2 Previous Next

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points