I write this question because I found only partial informations about my scenario.
In Azure to clone a VM, I need to deallocate and generalize, after I can create a lot of copy as many I would. The details that I didn't find are:
the VM generalized "cost" me in term of CORE ? After azure vm generalize , If I run azure vm list-usage the number of cores used decreased or not ?
if I generalize a VM with all users / groups / services configured (Apache, DB, etc.) in the same disk of VM, after generalize -> clone, I will find again this configurations in new cloned VMs ?
what are the parameters that I can change after generalization, ex. Availability Set, Network Security Group, Nic associated, etc. ?
Thanks
the VM generalized "cost" me in term of CORE ? If I run azure vm list-usage the number of cores used decreased or not ?
Yes, it costs you in the term of CORE. However, you don't need pay for the VM. You only need pay for the OS and date VHDs storage account. When you use vm list-usage, you will find the core CurrentValue does not change. When you delete the VM, the cores will be released.
I will find again this configurations in new cloned VMs
Yes, you could. Sysprep removes all your personal account information, among other things, and prepares the machine to be used as an image. More information please refer to this link. For a Linux VM, please refer to this link.
what are the parameters that I can change after generalization, ex.
Availability Set, Network Security Group, Nic associated, etc. ?
You could use the generalized VHD image to create any VMs. All of them you could associate to the new VM. More information about how to create a VM from a generalized VHD image please refer to this link.
VM's are billed according to their capacity, not on the basis of whether they are generalized or not, a vm and a vm created from generalized vm would cost the same (granted they are the same "size").
this question has nothing to do with azure, it's just a syprep. Azure adds nothing to this process.
Anything you would expect when creating a new VM.
you need to understand the basic concepts behind virtualization to understand what is going on there.
https://en.wikipedia.org/wiki/Virtualization
Related
we have a working Netapp with ESXi (VMWare 5.5) setup. With multiple VMs running on 3 ESXi Systems but they are residing entirely on Netapp Storage.
We are thinking of moving this entire setup to private Cloud consists of HP Nimble cloud storage. This cloud is currently owned by one of our departments and are ready to give us space(in terms of storage) and ESXis(VMI Cluster) to run our VMs on a rental basis. So immediate advantage for us is more space, more network speed, DR Setup and not anymore worry about the hardware.
Ofcourse it is in discussion phase but I still would like to ask you experts following questions.
Netapp Storage is all about data plus its configuration (Snapshot, User Quota Policies, Export Rules etc.). When we talk about storage space in cloud, then how are we going to control/administrate the configuration parts listed above? Or will this not be anymore possible to administrate? And the Cloud administrators take this control in their hands and we have to be dependant on them for every configuration changes? This is very important factor.
Will VMs running on Netapp Storage be migrated without much efforts? Is there any documented method for this?
Your view on this will be really helpful.
Thanx in advance.
Regards,
Admin
On point #1, a common way to provide multi-tenant administrator access on NetApp is to create a separate SVM [1] (Storage Virtual Machine) that a tenant administrator can use to manage volume capacity, snapshots, quotas, etc.
For #2, a common migration path for moving VMware VMs is to use Storage vMotion [2]. The private cloud provider can remap the ESXi hosts in your environment to be managed under their vCenter Server first. Then from there, they will have the ability to (non-disruptively, in most cases) move the VMs from your old NetApp datastores to new datastores on their array. They can do the same for vMotioning these VMs over to their managed ESXi hosts.
[1] https://docs.netapp.com/us-en/ontap/concepts/storage-virtualization-concept.html
[2] https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.vcenterhost.doc/GUID-AB266895-BAA4-4BF3-894E-47F99DC7B77F.html
I have 4 VMs in azure and I am trying to set up a schedule to lower the RAMs and CPU cores for after-hours and revert them back to their original size during business hours.
can someone guide me through the steps or share a how-to resource, please? I can't find any documents and I am sure my search key is not correct.
Thanks
As suggested by #harshavmb, you can make use of VMSS.
In Azure, Auto-Scaling is possible if you make use of Virtual Machine Scale-Sets.
Virtual Machine Scale-Sets allows you to automatically scale as resource demand changes.
Based on schedules, you can create auto scale rules.
These schedule-based rules allow you to automatically scale the number of VM resources at fixed times.
To create the Auto-Scale rule, you can make use of following tools:
Azure PowerShell
Azure CLI
Azure template
Otherwise, you can create an automation account in Azure and execute runbooks as mentioned in below link if helpful:
Automatically Resize an Azure VM - Automation account
If I setup a server running my application on an azure instance, for example A1 can I later change the instance to D2?
I might want to experiment with a VM at a lower cost but then move to a higher performing machine at a later date without having to rebuild everything.
Yes, you can change the size of Azure VM on demand. Changing the size will trigger a machine reboot and if you're using a configuration with SSD temporary drive, the content of the SSD will get erased. Other than that, everything else will be left untouched.
Drew, the Principal PM in this area has a great blog here about this.
You can only resize a VM to another offering that does not have fundamentally different hardware. Since A-Series and D-Series VMs have similar hardware, you would be able to swap those two around. You would not be able to go from A-Series to G-Series though. In addition you need to look at VM availability per region if you want to swap to something only in certain areas, as well as look at if you are using an ASM or ARM VM.
If you have an existing VM, you can check what it can swap out with in the new portal under "Size" in the VM Settings.
This will allow you to reboot into a different machine type, however any temp storage will be erased as with any VM reboot. You just need to ensure you are storing your persistent data in external storage.
You can learn more about the VM size offerings here.
am new to windows azure. I recently set up a vm and host a website, according to the SLA i need to have 2 VMs in the availability set. Now i did set up the second VM.
My questions what do i need to use the second VM for?
if i setup load balancing does azure redirect user to the second VM? this second VM has nothing in it.
Please i will like to know this and is it possible to replicate the content of the first VM to the second one, so each time the first one is down the second VM can take over.
Thanks
At first, You must understand the statement of minimum two machines to get 99.95% SLA. It is not about "reserving" resources for use in case of fault or update (fault domain and update domain in availability set). Your application must be created as multi-tenant, so You need to run Your application on two servers, connected to the availability set. You can synchronize storage with GlusterFS (if You use Linux) or other distributed file system. You also can use Azure Files service (SMB as a service) to share storage. For sharing DB (in example MySQL) You need a cluster (independent or distributed through Your two machines).
So... You must to start think in "cloud way" instead of typical one VM administration.
I would like to achieve a high-availability scenario on two VMs in Azure.
I understand and can follow the directions here:
https://www.windowsazure.com/en-us/manage/windows/common-tasks/manage-vm-availability/
However, my question is this: are the two VMs supposed to be exact replicas of each other, so that when one goes down, the other takes over? Or does the Availability Set look after this, so that the two VMs can have totally different content and still utilise each others' free resources?
If you're working with Virtual Machines (currently in Preview), then each VM lives in its own VHD. You can make additional instances by creating a VM from an image you build, but at that point, the new VM lives in its own VHD and the actual disk image will then deviate from any other instance as time goes forward. Of course, if each VM is created from the same image, with the same initialization tasks, etc., then they'd have the same software as well. You'd be responsible for upgrading software versions on all the VMs. If you then put these multiple Virtual Machines in an Availability Set, you'd be assured that the Host OS (underlying OS at machine-level) for the VMs you have would not be updated at the same time. You'd also know that different VMs in the Availability Set would be situated in different racks, network segments, etc.
More on Availability Sets: Within an Availability Set, you may have any variety of Virtual Machines - Linux, Windows, different functionality. And... you may define more than one Availability Set.
In the PaaS world, where you set up a Cloud Service with Web and/or Worker roles, those VMs are spawned the exact same way. So adding instances means adding more of the equivalent VMs. If the disk crashed, a new VM would be created just like the others. There are no persistent changes to those OS disks. In the case of Cloud Services, there's fault domains and upgrade domains, which are very similar to availability sets.