Creating Multiple 'Profiles' to provide different 'Load outs' to Windows10 VM

[DoeBoye]

Hello all,

 

For some reason, I can't seem to get this working. I'm trying to take a Windows 10 VM that is set to run with 8 cores and 8GB ram, and create an alternate VM that uses 16 cores and 16GB of ram.

 

The point would be when I need some extra horsepower, I could simply start the more powerful VM. My goal:

 

1. 2 identical XML sheets except for CPU and ram

2. Share the same image file (If possible)

 

Is this (Or something like this) possible, or am I crazy?

 

[SpaceInvaderOne]

It works with Linux and osx VMS.

However  windows VMS don't like it because of uuid

eg

<uuid>98e3dac0-cffc-cffe-807e-1d9b4ebd1cc1</uuid>

Windows uses the uuid for actvation. So a different xml template will have a different uuid. and templates with the same uuid is not possible.

 

A way around it is to

1. Setup first windows VM giving it a boot vdisk that is as small as possible for the OS to work. Then have a second much larger vdisk and

use as the second hard drive's drive'. Then install all programmes onto this larger vdisk  (D drive) and make the location for documents desktop etc to be on the D drive.

 

2. Then create second windows VM in the same way. With a small vdisk for the os. But for this ones  second vdisk to the same vdisk as the first VM's uses. Choose different CPU count memory etc for this template if you want.

Install the same programmes as the first VM and to the same location (second vdisk) and set the location of the docs/desktop etc to the same as the first windows VM.

 

This way both vms will be the same and documents the same between them but can have different cpus etc

[bungee91]

It works with Linux and osx VMS.

However  windows VMS don't like it because of uuid

eg

<uuid>98e3dac0-cffc-cffe-807e-1d9b4ebd1cc1</uuid>

Windows uses the uuid for actvation. So a different xml template will have a different uuid. and templates with the same uuid is not possible.

 

A way around it is to

1. Setup first windows VM giving it a boot vdisk that is as small as possible for the OS to work. Then have a second much larger vdisk and

use as the second hard drive's drive'. Then install all programmes onto this larger vdisk  (D drive) and make the location for documents desktop etc to be on the D drive.

 

2. Then create second windows VM in the same way. With a small vdisk for the os. But for this ones  second vdisk to the same vdisk as the first VM's uses. Choose different CPU count memory etc for this template if you want.

Install the same programmes as the first VM and to the same location (second vdisk) and set the location of the docs/desktop etc to the same as the first windows VM.

 

This way both vms will be the same and documents the same between them but can have different cpus etc

 

Wouldn't the biggest downfall of this solution be that you'd have to have two Windows licenses?

At that point it'd just be easier to edit the VM each time as opposed to keeping two VM's patched and updated.

[SpaceInvaderOne]

That's true.

You could i guess just swap xmls by making a user script using rsyn to swap the files in the /etc/libvirt/qemu

but that would be as awkward as just editing the scripts. Would be more useful though if you had custom edits in the xml such as gpu rom files.

 

I am lucky I have a few 10 licences i got for free.

A friend recently bought 10 pro very cheap from playasia @ $24  here  http://www.play-asia.com/microsoft-windows-10-pro-3264-bit-oem/13/709747

 

[bungee91]

True, I can certainly see the use case as recommended with more advanced manual XML edits performed for a VM.

I guess we're both telling the OP, no not really, or easily anyway. 

 

There was a thread on here to hot swap CPU's, as libvirt apparently allows for such actions.

Seemed a bit complex, but a script was posted in that respective thread. Doesn't help too much with memory allocation however.

[DoeBoye]

Sigh. I kinda thought this might be the case. Sounds like manually editing the XML when more cpus/ram is desired is the easiest way.

 

Thanks for the input, folks!