Hi,
Petrus B. van Bork wrote:
Had some 'tap-dance'
at the virt-manager site (which I will deal with later)
Just wondering what issues you had. If the documentation to build
from source isn't clear I'd like to improve it.
CloneManager.py, on my machine, as per the first link Cole, so
kindly,
provided. I deleted the one line shown in red with a minus, and added
the following line, in green, with a plus (...just for the record).
This resulted in virt-clone running - but very touchy. After the change
virt-clone would still not run interactively - it would ask for a disk
and go back to the prompt and it would not run with a full string of
command line switches
I'm a bit confused. I see below that just running 'virt-clone' fails
(this is a bug that needs to be fixed) but a full string of cmds
fails as well? I can't seem to reproduce this.
(...as illustrated in my last email and Cole's
reply). It would, however, run:
#virt-clone -f foo.dsk
...at that point it would ask for several things, including the original
clone's UUID or name (...this for those trying it for the first time,
seems to need the Virtual Machine Manager running and connected to the
Xen hypervisor but, of course, with the DomU to be cloned "Shutoff").
When the cloning began it started with:
libvir: Xen Daemon error : GET operation failed:
libvir: Xen Daemon error : GET operation failed:
...then I got - to my relief...
Cloning from /home/xenguest/hanoverguest.dsk to KohaHanoverConf_Gold.dsk
...this worked...sort of...no more error messages BUT the result I ended
up with was:
* an .sxp file that did not have a disk path to the .dsk,
* and it was missing a number of other things as well such as the
reference to localhost:5900
* tried running "xm create" But...xm create would not run command
xm create -c /... path to UUID/config.sxp resulted in:
Error: Errors were found at line 5 while processing
/var/lib/xend/domains/...UUID.../config.sxp: (VCPUs_live 1) - alas, this
was the 100% identical line from the config.sxp that it was lifted from
(...the running DomU).
* virsh didn't like the .sxp either and I was not sure how to create
an xml for it to read, just don't know enough and not enough
documentation available.
After a successful virt-clone, the domain will already be defined. This
means both virsh and xm know it exist. You shouldn't need to run xm
create at all: just try 'virsh start cloned_vm_name' or
'xm start cloned_vm_name' and the guest should run.
virsh doesn't sxp files, it uses xml. Try 'virsh dumpxml cloned_vm_name'.
At the end of the day - another day spent fruitlessly trying, trying,
trying... I am a little further than yesterday but I am no further than
I was this morning. Still completely unable to get the new cloned DomU
to run. Using #xm start <domainName> changes the status to 'running' in
Virtual Machine Manager but with 0 CPU usage and RAM usage. Does anyone
have any idea what is wrong? I am still in the dark and would still be
most grateful for any more illumination on this!
Best,
P.
-------------------------------------------
Other Issues with virt-clone after fix, this morning:
#virt-clone
...result: ERROR: A new disk image file for the cloned guest is
required, followed by a command prompt... [...no interactive
functionality available, as yet...]
As mentioned above this is definitely a bug.
#virt-clone -f testdisk.dsk
..result "What is the name or uuid of the original virtual machine?
[...which is the correct response but you have not fed the script a path
and will result in a config.sxp with no path for the disk!]
This is also a bug, we should put the full path in the cloned guest config.
#virt-clone -f /var/lib/xen/images/testdisk.dsk
...result: ERROR: Disk size must be an in or a float.
What would you like to use as the disk path?
[...problematic...can't seem to use '-f' switch, as per man syntax,
unless I have misread the man....)
I can't reproduce this. -f and --file should give the exact same
result: they literally call the same functions.
#virt-clone --file /var/lib/xen/images/testdisk.dsk
...result: "What is the name or uuid of the original virtual machine?
So...my question to Cole: "Does the version from the virtual manager
site, as per your second provided link, fix the above as well? Or, not
yet?" Obviously, if the material at the repository is better/later, I
will use it, once I figure out "hg" - which is 'unknown command' on my
system, presently.
The 'hg' command belongs to the mercurial package (intuitive, I know.) To
use the upstream checkout, try this:
yum install mercurial
hg clone
http://hg.et.redhat.com/virt/applications/virtinst--devel
cd virtinst--devel
./virt-clone insert-args-here
Let us know how that goes and if you are still encountering above
issues I couldn't reproduce.
Thanks,
Cole