topic Re: IntegrityVM : Offline-migration and missing boot-disk in Operating System - HP-UX

IntegrityVM : Offline-migration and missing boot-disk

Danny Petterson - DK — Mon, 30 Apr 2012 08:21:31 GMT

Hi Gurus!

A short description of my problem:

I have a filesystem with about 8 VM's (file-based backing store), running on 11.31/IntegrityVM 4.2. I need to migrate them to another machine, running 11.31/IntegrityVM 6.1. To make it a bit easy, this is what I plan to do (and trying actually):

1 - export the filesystem with all the VM's using NFS

2 - mount the NFS-filesystem on the target-system using the same mountpoint

3- Make an offline-migration

4- When all VM's are offline-migrated, unshare and export the VG containing the VM-filesystem on the soruce-system, import the VG on the target system, mount it where the NFS-mount was done earlier

5- Start the VMs

For testing purposes I just tried 1-3 for one VM, and it works as it should - or so it seems.'Cause when I boot it on the target system, after an successfull offline-migration, it can't find the bootdisk - it is visable and looks fine when I check with hpvmstatus for the particular VM, but the EFI cant boot - even though the hardware-path looks like the one on the source, and the path to the file backingstore is the exact same.

Is it some kind of NVRAM-problem for the VM; and if yes how do I correct it?

Or something else?

Thanks for your time.

Greetings from

Danny Petterson

Re: IntegrityVM : Offline-migration and missing boot-disk

Eric SAUBIGNAC — Tue, 01 May 2012 10:39:50 GMT

Bonjour,

Do you mean that you can't boot from the menu, that is from the registered entry, something like "HP-UX Primary Boot: ...." ?

Do you see the boot disk at EFI level with the "map" command ? Do you see any filesystem "FSx" ? If yes did you try to boot straight from the SHELL EFI with a sequence of commands like "FS0:" then "hpux" ?

The idea behind is that the disk's signature, provided by HPVM, could be different when using the same file with 2 different methods (local file vs. nfs file). Because the disk's signature is recorded with the registered EFI entry "HP-UX Primary Boot: ....", you can't boot if the signature is modified, even if hardware pathes are the really same.

Eric

Re: IntegrityVM : Offline-migration and missing boot-disk

Danny Petterson - DK — Tue, 01 May 2012 13:47:15 GMT

Hi!

Thanks a lot for your reply.

Well, I mean...both. It is not working from the "HP-UX Pirmary Boot...."-menu, nor is it available from EFI with the "map"-command - neither is any other disk, even though two disks are avilable when you check "hpvmstatus" for the guest (only one for booting though).

So it seems very possible, that it is due o the disk signature being different because the file is accessed in two different ways.

The funny thing is, if I start it again on the "source"-host, then it all works well.

Any way I can change the signature, and make it work, after the offline migration?

Again, thanks a lot.

Danny

Re: IntegrityVM : Offline-migration and missing boot-disk

Eric SAUBIGNAC — Wed, 02 May 2012 07:25:59 GMT

1) Well, if you don't see any disk with the EFI command "map", the problem has probably nothing to do with disk signature.

I never used NFS for backing store ... and not sure I will do it in the future. So I have no real background to help you. But, could you have a problem with NFS access rights ?

2) An other question could be : are you sure that hpvmmigrate is supported between HPVM 4.2 and vPar 6.1 ?

May be you could replace in your procedure the "offline vmmigrate" with a cold creation of the VM on the target system. The only important point is to create the VM with the same virtual bus adressing than the source VM.

And since the VM is "cold" created, you will have to boot manually on the target system then create the EFI boot entry with setboot.

An other point when moving a VM guest to a new host without the command hpvmmigrate could be to align uuid (for things like licences, SAP for instance). Check this thread http://h30499.www3.hp.com/t5/Virtualization/quot-uname-i-quot-on-HPVM-Guest/m-p/4595616

Finally, hpvmmigrate aligns NIC ethernet adresses. If you need to have the sames, you will have to do it manually.

3) an other question, probably silly and not sure that it could explain why you don't see your NFS backing store at EFI level : what is the OS Version at Guest level ? In vpar 6.1 only guests with 11iv3, beginning with March 2010, are supported.

4) Without NFS, and expecting that your source FS is located on a shared storage, you could also :

- import the VG on the target host

- activate it in Read-Only on the target host

- mount it in Read-Only mode to the final location on the target host

- offline migrate your VM (don't try to start them !)

- once migrated umount and de-activate it on the target host

- stop yours VMs

- export defintively the VG from the source host

- then, activate an mount it normally on the target host.

- start the VMs on the target host

Eric

Re: IntegrityVM : Offline-migration and missing boot-disk

Danny Petterson - DK — Wed, 02 May 2012 08:37:47 GMT

Hi again Eric!

Im very happy you take the time for this dialouge :-)

Nope - should not be a problem with rights - root on the target VSP can create, delete, edit files on the share without any problems

Hm - I have not checked if offline migration is supported between 4.2 and 6.1 - however, usually the hpvmmigrate-command is very sensitive, so I did expect it to complain if it was not supported - however I will read up on it

Hm - might not be a silly question after all - I acutally forgot to check that (embarrasing) - 'cause this is actually a version of 11.31 a bit older than 1003 - does this explain why I can't see the disk in EFI? Shouldnt it just fail? But thanks, a very valid point

More or less what I would do when moving all the VM's - the NFS part was just for testing the move for the none-prod VM's - to find caveats like the OS-problem above ;-)

I will get back later - thanks a bunch!

Kind regards

Danny

Re: IntegrityVM : Offline-migration and missing boot-disk

Danny Petterson - DK — Wed, 02 May 2012 14:20:52 GMT

Well - as for 3) OS Version:

I updated the VM to 1203, no difference ,still no devices present when I boot on the target VSP.....

Re: IntegrityVM : Offline-migration and missing boot-disk

Torsten. — Wed, 02 May 2012 14:31:40 GMT

AFAIK only version 4.3 supports NFS based boot/root filesystems for only 11.31 guests - version 4.2 doesn't.

Re: IntegrityVM : Offline-migration and missing boot-disk

Eric SAUBIGNAC — Thu, 03 May 2012 08:01:10 GMT

Bonjour,

So what are the differences between a 4.2 VM and 4.3 / 6.1 Guest ?

- Supported OS in the VM Guest. OK, you've done an upgrade.

- Librairies tools you must install in the guest. I mean the depot located on the VM host @ /opt/hpvm/guest-images/hpux/11iv3/hpvm_guest_depot.11iv3.sd Have you done this upgrade ? I don't see how it could help to see the virtual filedisk at EFI level, but you are supposed to do this upgrade ...

- Finally the nvram file of the guest. I mean, I don't know exactly from where the EFI is loaded for a guest. If it is loaded from the nvram file, and because you have used the hpvmmigrate command, then this EFI is coming from a non supported version of HPVM on an NFS backing store (Torsten's post). I think that point 2) must be more investigated.

Could you do a small test ?

- Create, from the old host, a new filedisk on the exported FS.

- From the new host create from scratch a dummy Guest with just one disk that point on the NFS filedisk you've just created.

- boot this new VM, and check from the shell EFI if you can see the corresponding blk: device

If you can see the disk

then shutdown the VM

copy the nvram file from a migrated 4.2 VM to the new VM

try again

do you still can see the disk ?

else

well ... no more idea :-(

And, yes. Finally the usual question : have you carrefully read HP vPars and Integrity Virtual Machines V6.1 Administrator Guide (5900-1577, March 2012) ? More exactly chapter 9.2.2.4 NFS-Mounted backing stores for root, swap, and dump, page 132

Eric

Re: IntegrityVM : Offline-migration and missing boot-disk

Stan_M — Thu, 03 May 2012 08:35:36 GMT

In order to see the device in EFI you may need to enable enumeration (look for drvcfg in admin manual).

If it's not seen even with enumeration enabled, review guest log file under /var/opt/hpvm/guests/guest/

for any mapping errors.

Re: IntegrityVM : Offline-migration and missing boot-disk

Torsten. — Thu, 03 May 2012 09:18:48 GMT

Whats new in version 4.3:

Support for NFS guest back stores for root, swap, and dump. For information, see Section
6.2.2.4 in the HPIntegrity VirtualMachines4.3:Installation, Configuration,Administration

Re: IntegrityVM : Offline-migration and missing boot-disk

Danny Petterson - DK — Tue, 08 May 2012 08:51:20 GMT

Hi everybody!

First - thanks to everyone for taking interest.

Torsten:
Only the VSP running HPVM 6.1 is using NFS-mount, The 4.2 host is using local disk - I tried to discribe that in my initial post.

Stan:
Good idea - however enablement of the enumeration did not solve it.

Beside that:
When looking at the output on the two VSP's, "hpvmdevmgmt -l all" shows a distinct difference for the guest-disks, where the target-system is aware of the NFS-disk - I DID hope it would only look at the path, not the way the disk was presented to the VSP. But it was painfully aware of the NFS-circumstances, which I suspect is the reason it won't work. And yes, it was mounted with all the right NFS-options for HPVM (hard, tcp, version 3).

So this is what I ended up doing:

-Preview export to mapfile of the VG with the filesystem where all the VM's reside - on the source-system
-Move the mapfile to the target-system, import it, activate it in read-only mode and mount it as read-only
-Shutdown all VM's on the source-system, and migrate them to the target
-Unmount and deactivate the VG on the source
-Unmount, deactivate and reactivate/mount in rw-mode on the targest-system
-Startup the VM's on the target

Not at all as flexible as I would have liked it to be, and not possible to test-migrate a few VM's at the time - but it worked.

Thanks again everybody - does anyone have some further academic input for this scenario, please share it, it would be very interesting.

Kind regards
Danny