[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libguestfs] [PATCH 2/2] Use an internal representation of domain metadata



On 15/03/11 11:47, Richard W.M. Jones wrote:
On Fri, Mar 11, 2011 at 01:34:48PM +0000, Matthew Booth wrote:
[...]

You seem to be convinced this is better, and I'm not going to argue
with that, so ACK to the patch in general.

I have specific comments on the fields you are (not) preserving below.

+%
+  name          The name of the domain

I think you need to include the /domain/description free text field
here too.

Also /domain/uuid seems pretty important.

Ok.

Is there nothing /domain/os which is important?  How about
/domain/os/sysinfo (SMBIOS information).

For more esoteric stuff like this, I would prefer to wait until it's actually shown to be a problem in practise.

+  memory        The memory assigned to the domain, in bytes

I'm assuming that virt-v2v no longer runs on 32 bit architectures (or
else sizes in bytes tend to get converted to floats and rounded
awkwardly).  Is there a check for this, like the one in virt-resize?

http://git.annexia.org/?p=libguestfs.git;a=blob;f=tools/virt-resize;h=4beb45b57df315e551ecb4be8b3748e2a565eeb0;hb=HEAD#l33

Nice. I hadn't actually considered this at all. Is there any way to make perl do 64-bit integers?

+  cpus          The number of cpus assigned to the domain

CPU topology?  This appears to be important for performance -- we
recently discovered that the performance of 1 [virtual] socket with 4
[virtual] cores is quite a lot worse than the performance of 4
[virtual] sockets each with 1 core, because the guest OS schedules
things differently.

I'm currently completely ignoring topology for libvirt targets, and defining N single-core CPUs for RHEV targets. How important do you think this is? I don't see this as a major issue to include, but I'd prefer the simplest possible solution.

I would also preserve libvirt's lifecycle actions,
/domain/on_poweroff, /domain/on_reboot and /domain/on_crash, unless
you know otherwise.

I can include these.

+  arch          The architecture of the domain (eg i686,x86_64)
+  features[]    An array containing 'features', as defined by libvirt
+  disks[]       An array containing hashrefs of disk descriptions
+    device          The name of the disk as seen by the guest (eg sda)
+    path            The path to the device's storage, as known to the source
+                      or target hypervisor. This will probably not be a valid
+                      local path
+    (local_path)    A local path to the device's storage, as usable by
+                      libguestfs during conversion. This is populated by
+                      copy_storage()
+    is_block        1 if the device uses block storage, 0 if it uses a file.
+    format          The file format used by the underlying storage, as known to
+                      qemu (eg raw,qcow)

I have no idea if we should be trying to preserve the
/domain/devices/controller elements and/or
/domain/devices/disk/address (to avoid Windoze reactivation).

I don't think so. Windows reactivation is basically unavoidable as so much changes.

+  removables[]  An array containing hashrefs of removable media devices
+    name            The name of the device, as seen by the guest (eg fd0)
+    type            The device type, as defined by libvirt (eg floppy,cdrom)
+  nics[]        An array containing hashrefs of NIC descriptions
+    mac             The mac address
+    vnet            The name of the virtual network the NIC will connect to
+    vnet_type       The type of virtual network the NIC will connect to, as
+                      defined by libvirt (eg network,bridge)

Sound cards?

Well they're specifically a source of problems ;) The current code removes them explicitly. I'm happy to leave these out for the moment.

It's also worth mentioning that Dan Berrange suggested on IRC that serial and parallel devices should be preserved.

Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team

GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]