> I'm just wondering what the licensing reason for moving back to a
> physical, is it because the vendor wants to license all of the
> sockets in the ESX cluster rather than the virtual CPU's that are
> assigned to the guest?
Pretty much.
> If that's the case, I'm just wondering if it might be easier to run
> the boxes as standalone ESX servers, it kinda sucks from a
> virtualization point of view, but might get you round your issue
> with as little pain as possible.
Hmmm ... I will mention it. But I think my boss has his heart set on a
stand-alone physical machine, not running as a VM ... there may be
licensing details that I am not aware (i.e., different pricing for
virtualization vs physical, regardless of pricing for number of CPUs, etc)
> If that's not the case, you could get the machine(s) cloned as an
> initial step, and then run the sysprep over the clone - at least
> then you fall back would be just to power up the original VM.
But I couldn't fall back. The sysprep would change the SID, so the VM
would not be able to authenticate to the domain again. I would need to
sysprep the clone, and then re-join the domain. That would stop me from
using the VM again.
>
>
> Mat
> -----Original Message-----
> From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU
> ] On Behalf Of Michael Leone
> Sent: Wednesday, 16 November 2011 1:47 AM
> To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
> Subject: [Networker] OT - migrating a VM to a physical machine
>
> I realize this is a bit (OK, maybe a bit more than a bit ..) OT. But
> I will be using Networker in the process, so I thought I'd ask here.
>
> VMware Environment: 6 host EX 4.1 U1 cluster. VM in question -
> Win2003 Enterprise, 32 bit
>
> My boss tells me that I need to convert this from a VM back onto a
> physical machine - for licensing reasons, this needs to be a
> physical box, apparently. And there's no budget for software
> designed for this purpose (of course :-)).
>
> So here's the big rub ... this VM is one of those mission critical VMs.
> Ordinarily, what I might have done is do a sysprep of the VM, and -
> before shutting it down - do a full backup using Networker. Then, I
> would do a BMR (Bare Metal Recovery) of Windows on the new physical
> hardware. That way, after the reboot at the end of the BMR, sysprep
> would run, find the new disk controller drivers, etc, and not blue
> screen with inaccessible boot device errors.
>
> However, my boss has vetoed that idea, since we can't take any
> chances with the VM perhaps not working after the sysprep. If that
> BMR doesn't work, then I would need to turn the VM back on. and we
> have no guarantees that it would continue to work the same after the
> sysprep, etc.
>
> So my hands are tied that way.
>
> Then I thought - well, we could still do a BMR, but without the
> sysprep first. I could install the drivers for the new disk
> controller, etc, into the running VM. Do a regular full backup,
> shutdown the VM, and then do the BMR to the physical box. It should
> recognize that the hardware has changed, see the new hardware, see
> it has a driver for it, reboot accordingly. Repeat until it's happy
> and boots normally. If absolutely necessary, do a Windows Repair
installation.
>
> That way, either the physical box would work, and I'd leave the VM
> powered off, or the physical box would fail, and I would power the
> VM back up.
> Since the domain SID never changes, all should be happy.
>
> I think that should work. Anyone ever done anything similar? The BMR
> should just be: install same version of Windows onto physical
> hardware (no need for updates) with same name and IP address, not as
> member of domain.
> Install NW client (same version as what's in the VM). Do a full
> restore of everything except the NW client program files folder.
> Reboot when prompted. That should work as a BMR for a 32bit Win2003 box,
yes?
>
> To sign off this list, send email to listserv AT listserv.temple DOT edu
> and type "signoff networker" in the body of the email. Please write
> to networker-request AT listserv.temple DOT edu if you have any problems
> with this list. You can access the archives at http://
> listserv.temple.edu/archives/networker.html or via RSS at http://
> listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
>
> We're behind the Bid!
> GOLD COAST 2018 - XXI COMMONWEALTH GAMES CANDIDATE CITY
> www.goldcoast2018bid.com
>
>
*********************************DISCLAIMER*********************************
>
>
> The information contained in the above e-mail message or messages
> (which includes any attachments) is confidential and may be legally
> privileged. It is intended only for the use of the person or entity
> to which it is addressed. If you are not the addressee any form of
> disclosure, copying, modification, distribution or any action taken
> or omitted in reliance on the information is unauthorised. Opinions
> contained in the message(s) do not necessarily reflect the opinions
> of the Queensland Government and its authorities. If you received
> this communication in error, please notify the sender immediately
> and delete it from your computer system network.
>
> To sign off this list, send email to listserv AT listserv.temple DOT edu
> and type "signoff networker" in the body of the email. Please write
> to networker-request AT listserv.temple DOT edu if you have any problems
> with this list. You can access the archives at http://
> listserv.temple.edu/archives/networker.html or
> via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|