Using virt-manager to create a vm by copying, not cloning an established vm faulters / fails. The copy mode is an added feature to virt-manager from prior versions. It should do the same as copy used in debian's xen-tools, but it doesn't manage it. The expected outcome is to copy a vm into a new selected image or disk space. The outcome is that it attempts to boot into the source vm, which is problematic, depend on the state of the vm. Can't really try this feature out to observe how it goes about it because it loses its way and does nothing towards copying the vm. Invoke virt-manager, and select new to bring up the create image tool. Select the final option check box, import existing disk image. Proceeds to the next couple of screens, selecting the source vm to import from, and memory and cpu settings. Then it loses its way. It misses a screen. The next screen should be to select a storage for the new vm. It skips past it to the final screen. In doing so, it appears to then miss creating the matching entry in libvirt. You can manually backtrack to the screen it missed, just selecting back once. Then you can nominate the storage, but it doesn't register. Once again, virt-manager of this version has a back dooor. Select the checkbox to customise configuration before install. This may or may not work. In this case, selecting finished drew another anamolous error, File "/usr/lib64/python2.6/site-packages/libxml2.py", line 1263, in parseDoc if ret is None:raise parserError('xmlParseDoc() failed') parserError: xmlParseDoc() failed I unchecked this box and clicked finish. It made the storage, and entered the vm into virt-manager, though stopped. The new vm window does not disappear because it is in error. This occurs, the new vm window shouldn't still exist once the vm is registered in virt-manager. Now that there is an entry in virt-manager, we can procure a printout of its actions. This time it didn't record in virt-manager.log or virt-install.log for some reason, but no mater. There is the xmldump. The new vm just attempts to boot the established vm. Booting it is not the required intention, but to import the image. It never creates the storage volume into which to import it using the screens. We now have a vm console to work with. Creating the storage manually using the vm window doesn't help. Adding it, it is not recognised and used as a storage into which to import. It becomes just another virtual or physical disk. The procedure just fails in its mission. The created vnc vm console isn't really purposeful. It can be started, but in this case just closes up after a few seconds because it can't boot. That's long enough to acquire the dump. Here is the dump of the vm <domain type='xen' id='7'> <name>sample</name> <uuid>11a715a9-1bf9-7306-bded-e8b7e1d7187d</uuid> <memory>282624</memory> <currentMemory>282624</currentMemory> <vcpu>2</vcpu> <os> <type>hvm</type> <loader>/usr/lib/xen/boot/hvmloader</loader> <boot dev='hd'/> </os> <features> <acpi/> <apic/> <pae/> </features> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/lib64/xen/bin/qemu-dm</emulator> <disk type='file' device='disk'> <driver name='file'/> <source file='/mnt/fedora/windata/images/fedora8-linux/fedora8.img'/> <target dev='hda' bus='ide'/> <shareable/> </disk> <disk type='file' device='disk'> <driver name='file'/> <source file='/mnt/fedora/windata/images/fedora8-linux/clone8.img'/> <target dev='xvda' bus='xen'/> </disk> <interface type='bridge'> <mac address='00:16:36:65:03:d2'/> <source bridge='eth0'/> <script path='/etc/xen/scripts/vif-bridge'/> <target dev='vif7.0'/> </interface> <serial type='pty'> <source path='/dev/pts/6'/> <target port='0'/> </serial> <console type='pty' tty='/dev/pts/6'> <source path='/dev/pts/6'/> <target port='0'/> </console> <input type='mouse' bus='ps2'/> <graphics type='vnc' port='5900' autoport='yes' keymap='en-us'/> </devices> </domain> The second the clone8.img is what I manually added. This being an added feature, I can't (yet) get to figure what entries it should have included. The libvirt docs probably outline it, but rectifying it manually is just a workaround. The vm should have been imported and copied. Occurs predictably every time, so far every time I've tried it. Skipping the screen it skips is the centre, the essence of the bug. That done, it can't recover to establish an effective config and thus an effective outcome of the selected process. It's the same outcome in squeeze, close to the same version, so I've put bugzilla redhat and debian bugs as cc. Perhaps I need to do that myself since in the last bug you asked me to do just that. If I get keen I might try debugging it some more, nut this info clearly described where in the process it goes awry. This is fairly minor, but nevertheless a bug. It's a feature, a broken feature that doesn't achieve.
(In reply to comment #0) please disregard this entirely. It is an import mode, not copy, and it works.
