Tag Archives: p2v

Migration weekend coming up

Because of the fact that we are now virtualizing servers that run our most critical production systems we aren’t moving as fast as we were in the beginning of our project. We have to plan most of the work either very early in the morning or in weekends like the one coming up.

This weekend we will be virtualizing nice Oracle servers of different flavours (8i, 9i, 10g, 9iAS and 10gAS). Because some machine were still using Suse Linux 8 (SLES8) we can’t PowerConvert them but in stead we have prepared Oracle 8i and 9i on SLES9 templates which will be used to generate the VM’s. After that it’s just a question of either mounting the database data already on the SAN or copying it over and mounting it. Following the recommendation from EMC we use RDM’s for all our Oracle databases so that’s exactly what we’ll do here.

After this migration weekend we’ll start at putting DMZ network into the VM hosts and configuring our virtual DMZ so we can start virtualizing our webservers.

Virtualizing a domain controller

The topic seems hot on the VMWare forums. One of the better posts I found in the Strategy & Planning section (forum post, this post started because of this post). That got me thinking about a DC that we put online just before Christmas and we found out that it wasn’t functioning properly.

We were able to fix the problem (the NTP Client on the ESX Server wasn’t running and because of that the DC wasn’t getting the right timing from our NTP server) and everything is running fine now. So in the end: if you put the DC in “Server mode” in stead of “Client mode” (which is the same as flipped the registry key mentioned in the first forum thread) and make sure your NTP Client is running on the ESX server than there is nothing to prevent you from not virtualizing your DC’s.

We are taking it slowly though. Our dedicated Exchange Global Catalog will remain a physical box for the time being and we will probably let the Primary Domain Controller be a physical box. (edit 04/01/07 – 17:17 — in this case I don’t mean the PDC as in the NT4 terminology, just to keep one main DC in physical form)

In my search for additional information I found some links that might be interesting:

The migration continues

Now that the cluster is complete and everybody is back from the holidays we can continue with our migrations.

First on the list is to clear out one of our VMWare GSX Servers with 15 VM’s on it and start with the Oracle database servers on Linux. We have already done several Oracle machines that were on Windows and one on Red Hat Linux so we are not expecting any problems there.

This all starts next week so expect the regular updates to pick up then.

MPR Week 9

After surviving an exhausting ISO 27001 audit I can now write something about our virtualization progress again.

My most imporant conclusion of this week is that virtualization is starting to be FUN ! We now have all the wrinkles out of the conversion progress and we can predict nearly exactly how a conversion is going to run.

Oh, and converting the first fileserver really was that simple. So simple in fact that I believe we can do the next 500GB and 600GB conversion in just under 15 minutes each. It’s so simple and fast that we could even do it without informing the users and they wouldn’t even notice it.

Memory utilization after 38 VM’s is closing in on the 50% mark on the hosts so action is needed there (see other post).

The other conversions were Oracle database servers on Windows and apart from having to copy 100GB from our other datacenter both went without problems. Even the necessary change in the IP address (which our DBA has told me is notoriously difficult with Oracle servers) gave no problems.

MPR Week 8

A lot has happened again in the last week.

First we cleared out our old GSX server. All the VM’s on that server are now on the Virtual Infrastructure hosts so the server count is up to 33 VM’s. We used VMware Importer for the transfer and that went without problems. The procedure is fairly straightforward and we used a Samba share on the GSX server to access the VM’s from the engineer’s laptop that was running the Importer tool.

This week we will PowerConvert two more machines, both Oracle database server on Windows 2003 server and start planning the migration of our large fileservers (600, 500 and 400GB respectively) and Oracle database servers (6 servers, varying in size from 140 to 250GB in storage). Because we are in the middle of a migration to a new EMC/Cisco SAN we have asked the EMC engineers about best practices in this area and have been advised to use Raw Device Mapping (RDM) for these VM’s.

This makes migration of these servers simpler in the way that we only have to unmount the volumes from the physical server, PowerConvert it, map the LUN to the ESX host and mount the disk in the new VM.

If it really is that simple you will read it here ofcourse.

MPR Week 6 – Thursday

Three conversions last Thursday and again something to write about.

I would like to report some sort of consistency in the process but it seems everytime there has to be something that needs extra attention.

In this case there were:

  • a SuperOffice application server. This time it was the virus scanner (McAfee) that refused to start up properly after the migration. Somehow it got installed twice. After removing it from the server and forcing a new installation from the ePolicy server and a reboot the problem was solved
  • a Biztalk 2004 server. Apart for an unexpected slowdown in transfer rates from our other office this went without a hitch
  • a Tridion Content Manager server. In contrast to our earlier migration of a similar server it turned out that because of a change in IP adress (we use a location based numbering system, this physical server was in our second datacenter) the license was invalidated. We requested a new license file from their customer support the next morning and got the server running normally

MPR Week 6 – Tuesday

This week we will migrate two servers: a Biztalk 2004 server and a Tridion Content Manager server. Both are development environments for one of our clients (development in this context means that we are running production on them as the custom application that we are building using these environments is the thing that we

Last week also saw the addition of the second VI3 host (we needed to make some space on our core switch) . The cluster was enabled and both machines were added to the cluster without anyone knowing that it happened. After this there was a slight problem getting VMotion to work but the solution was to make an actual gateway present (rather than using a fake one as was still possible in ESX2.5). So we made a small 192.168.x.x. network coupled to a separate vLAN and vSwitch which is used for VMotion as we don’t want that data, which is unencrypted system state data, going over the production network.

We also received some very encouraging news from Platespin regarding LVM support in the next version of PowerConvert so we are looking forward to the official announcement from them so we can have a new go at PowerConverting our Linux boxes.

MPR Week 5

Today we have converted two more machines. Again these were with PowerConvert and with a little tweaking they went smooth. We also tested the connectivity between our two datacenters with regards to conversions and that also posed no problem with the data coming into the ESX server with 30Mbit/sec, which is enough for future conversions. At one point the two conversions were running simultaniously with both streams making 30 Mbit/sec.

We did run into some problems again so I’ll list them for your future reference:

  • Virusscanner software interferes with PowerConvert
  • The time on the converted server must be equal to the time on the PowerConvert server before conversion starts
  • We use static IP numbers whenever (before, during and after conversion) we can but it turned out to be necessary to have a small DHCP scope in the LAN segment because somewhere in the conversion process either the new VM or the old server tries to get an IP address through DHCP.

One servers migration failed on datacopy. After some troubleshooting we tried it again but the conversion failed again. It turned out that the PowerConvert service was hanging from the previous attempt and PowerConvert tried to install it a second time (which failed ofcourse). A reboot of the server fixed that problem.

The conversion then failed again for unknown reasons. We then used the “Take Control” method of converting in stead of the LiveTransfer and that did the trick.

MPR Week 3 – Friday

Well, it turned out that the slow conversion of the second system was probably due to a problem with PowerConvert not assigning the fixed IP address. In the end we decided to enter it manually into the VM and then the conversion went on.

After the conversion the software didn’t want to start up all the services (which we later figured out could be software related because of the need for specific configuration of a local administrator account). When it seemed the conversion failed we shut down the VM and booted the physical machine. After adding that computer to the domain again (because the new VM uses the same computer account) all the services started up nicely. We will retry this conversion at a later date.

What we have learned:

  • After a failed conversion you need to put the original server into the domain again. This requires rebooting the machine so you can’t do this during operating hours (at least we can’t).
  • Because of the above point we will only LiveTransfer machines out of office hours. So while LiveTransfer is a nice option it gets you into trouble anyway if a conversion fails
  • We will put a small DHCP scope into our Server VLAN so we don’t have to use a different VLAN during the migration