Disk GUIDS, Partition UUIDs, and Cloning Raw disks

This is for discussing general topics about how to use VirtualBox.
Post Reply
sbpetrack
Posts: 13
Joined: 20. Sep 2014, 09:41

Disk GUIDS, Partition UUIDs, and Cloning Raw disks

Post by sbpetrack »

Several questions about the topic mentioned in the subject line please:

1. I created a Raw Disk .vmdk file; the physical disk has GPT (and protective MBR). When I look in the "Information" tab on the virtual media manager, it says that the UUID of of vmdk virtual disk is one thing, and it is different from the GUID of the physical disk. And when I run gdisk in the guest (which happens to be windows), I get a THIRD, different GUID for the disk. Is this a bug or do I not understand what is put into the UUID field of the Information tab of the virtual media manager?

2. I wanted to 'clone' the raw disk .vmdk file to get another raw disk vmdk file. All I really needed to that this clone have a different GPT GUID. But it seemed to me that anything i tried copied the data into a 'regular' virtual disk. Is it possible to make a clone of the raw diska that differs only in the GUID used to identify the disk? Do I need to make the partition UUIDs also different?

3. Suppose I would like to make a clone of the raw disk which differs from the original in both the GUID of the disk and also in the various partition IDs. If i use the command VBoxManage internalcommands createrawvdmk with the -partitions option, am I guaranteed that the GUIDs of the two virtual disks AND each partition UUID will be different?

I am interested in being able to ensure that the virtual raw disk has the SAME disk GUID and paritiion GUIDs as the original disk , and ALSO in being to ensure that they are different.

I apologize if it's staring me in the face in the documentation or the forum. I looked very hard, or at least I think i did. Thank you for the information.
mpack
Site Moderator
Posts: 39156
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: Disk GUIDS, Partition UUIDs, and Cloning Raw disks

Post by mpack »

"Raw" disk simply means to bypass the host OS filesystem. It is still virtual hardware, as is all hardware seen by a VM.

A virtual disk UUID is encoded in the header of the virtual disk (in your case, in the VMDK header). This serves to identify the disk for VirtualBox purposes and has nothing to do with any signatures written on the disk itself. In fact this is true for all disks, raw or not (since as already mentioned, "raw disks" are still just virtual disks). VirtualBox doesn't change anything on the disk surface when cloning a disk, so no, any GUIDs encoded in the disk contents will be unchanged, only the VirtualBox UUID will change.

If you create a "raw disk" covering a whole GPT disk then the virtual disk is of course also GPT partitioned, and you must use a guest OS that understands GPT partitions, including being able to boot from it if that is a goal. If you create a "raw disk" around a single partition on a drive then you have to supply a dummy partition map, which may be either GPT or MBR, again with caveats about guest OS support and bootability.

Any particular reason why you are looking at raw disks? I hope it isn't some nonsense about expecting better performance from an un-cached drive.
sbpetrack
Posts: 13
Joined: 20. Sep 2014, 09:41

Re: Disk GUIDS, Partition UUIDs, and Cloning Raw disks

Post by sbpetrack »

So if i understand correctly, if I use raw disk access for a GPT disk, then the guest OS will necessarily see the same GUIDS for both the GPT header of the disk itself and for every partition on the disk. There isn't any partition data in the .vmdk file, and in particular neither the GUID of the GPT of the virtual disk nor any GUID of any partition is there. (If i use the -partitions option or the -relative option, do i have some way to have a guest OS see the exact same set of partitions and data as the actual disk, just with all the GUIDs replaced by different ones? If you're curious as to why i need this, it's because I'm dealing with some software licensing that is is tied to the GUIDS (and over which i have no control), and I would like to test the various licensing options available on a single machine. It's helpful to have different versions running simultaneously, so i can compare side-by-side the effects of different choices. )

You ask why i wandered into raw disk territory. No, it wasn't for any nonsense about performance (although while on the subject, I think that it COULD be the case that raw disk access would be faster than file IO, yes? I certainly believe you that it ISN'T, but I would think that there are several reasons why one could hope that it will be faster when devs decide to make that a priority. But no, that wasn't relevant to me. In my case, it was simply part of a program to rid myself of Windows, finally, once and for all. I couldn't do this all at once, and in fact I was worried that for some time I might still need to boot WIndows natively. So i set myself the difficult task of being able to boot a machine natively into it's original Windows configuration when i need to, but to normally boot the exact same disks as a guest OS inside an Arch Linux host, which I installed on some free space I created on the same machine. I didn't want to have to somehow synchronize these two Windows installations. In fact, it seemed perverse to me that if my goal was to first contain WIndows inside Arch Linux and then with luck get rid of it, that there would be a stage when i had TWO WIndows installations. That was something i truly wanted to avoid.

It was quite a slog, and I learned more than i care to know about how WIndows ties itself to hardware so that a user will have to buy more lisences --- but I have succeeded in the end. I can dual boot Windows and Arch Linux; and if i boot Arch Linux, I can then boot windows inside it as a virtualbox guest , and the guest installation uses exactly the same (raw) disks as the bare metal installation that i would dualboot. I can run WIndows like a free-range chicken, allowing it full access to every corner of the hardware; and I can constrain the same installation to be cooped up inside an X11 window. For the moment my biggest problem is that the network when run as a guest is CONSIDERABLY slower than when run natively. This is true no matter if I bridge the network interface, use NAT, or bridge using virtio. But i hope that problem will be only temporary.
mpack
Site Moderator
Posts: 39156
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: Disk GUIDS, Partition UUIDs, and Cloning Raw disks

Post by mpack »

sbpetrack wrote:So if i understand correctly, if I use raw disk access for a GPT disk, then the guest OS will necessarily see the same GUIDS for both the GPT header of the disk itself and for every partition on the disk.
If the entire drive is mapped then naturally the guest OS can see the GPT partition maps, so yes, every UUID in there will be visible along with every other part of the GPT structure.
sbpetrack wrote:(If i use the -partitions option or the -relative option, do i have some way to have a guest OS see the exact same set of partitions and data as the actual disk, just with all the GUIDs replaced by different ones?
The partitions option allows you to map the contents of one or more individual partitions, instead of the whole disk. By definition this excludes all data outside those partitions from the view of the guest OS - which will include the host's partition map. Of course a partition image is not a complete disk image so can't boot on its own. Therefore you must include dummy (non raw) extents in the VMDK which provides the other partitions and metadata needed to make a bootable drive. Your dummy partition map can contain anything you want - but note that VirtualBox provides no tools for creating any of this. Typically you would grab a copy of an MBR partition map from elsewhere, and modify it using a hex editor. In theory you could do the same with a GPT partition map, but the latter includes CRCs to protect against corruption so hacking it would be a more complex affair - probably you'd have to find or write a custom tool.
Post Reply